Cells Are Text First⚓︎

Feature tables are written for people. That means every value begins as text, even when it looks like something more specific.

Given the users exist
  | name | age | active | roles         | state |
  | Mira | 34  | no     | Admin, Editor | draft |

Python receives those cells as strings:

[
    ["name", "age", "active", "roles", "state"],
    ["Mira", "34", "no", "Admin, Editor", "draft"],
]

The table looks typed because humans recognize the words. Python does not.

Looking typed is not the same as being typed⚓︎

Some conversions are obvious. Others are traps.

int("34")       # 34
bool("no")      # True
"Admin, Editor" # still one string

"34" can become an integer. "Admin, Editor" can become a list. "draft" can become an allowed state. But none of that should happen by accident.

Parsing is a table decision⚓︎

A table contract makes conversion explicit:

from typing import Literal

from talika import RowTable, boolean, field, split


class UserTable(RowTable):
    name = field("name", required=True)
    age: int = field("age", required=True)
    active = field(
        "active",
        parser=boolean(true_values=("yes",), false_values=("no",)),
    )
    roles = field("roles", parser=split(","))
    state: Literal["draft", "published"] = field("state", required=True)

This says:

• age should become an integer
• active should use the explicitly declared yes/no Boolean vocabulary
• roles should split one cell into several items
• state should be one of the allowed words

The important part is not the specific parser. The important part is that the meaning lives in one visible place.

The parser guide covers the concrete building blocks, from scalar parsers to lists and parser composition.