Missing, Empty, And Defaults⚓︎

One of the easiest table mistakes is treating missing and empty as the same thing. They are different authoring choices, and they usually deserve different behavior.

Missing means the field was not written⚓︎

In this table, there is no active field at all:

Given the users exist
  | name | role  |
  | Mira | admin |

A schema can safely say, "when authors do not mention this field, use the project default."

from talika import RowTable, boolean, field


class UserTable(RowTable):
    name = field("name", required=True)
    role = field("role", required=True)
    active = field("active", parser=boolean(), default=True)

Here, missing active can mean True because the field was omitted.

Empty means the author wrote a blank cell⚓︎

This table is different:

Given the users exist
  | name | role  | active |
  | Mira | admin |        |

The author included active, then left the value blank. That could mean "unknown", "not applicable", "intentionally empty", or simply "I forgot to fill it in." The table layer should not pretend those are all the same.

Sometimes empty is meaningful⚓︎

Some fields really do allow an empty or null-like value. Make that explicit:

from talika import optional, string


nickname = field("nickname", parser=optional(string(strip=True)))

The important habit is to decide. Once missing, empty, and default values are separate ideas, feature files become easier to review and parser behavior becomes easier to explain.

Defaults are schema-owned final Python values; they are not passed through a cell parser. Use a hashable, non-mutable static default for shared constants, and use default_factory for fresh mutable values such as lists or mappings.

Compare the concrete behavior for missing optional fields and present but empty cells.