Modelling states with Literal, Enum and TypedDict

Goal

Make the set of valid values and shapes explicit so that a checker catches typos and incomplete handling before the code runs.

Prerequisites

Type hints on the code in question and a type checker in the pipeline.

Steps

1. For a small closed set of string values used in APIs or JSON, use Literal["open", "solved"]; the checker rejects other strings and flags match/if chains that miss a case when combined with assert_never.
2. For values that carry behaviour or need iteration and comparison, use enum.Enum or StrEnum (members serialise as their string value).
3. For dictionary-shaped data with known keys (JSON payloads), declare a TypedDict with Required/NotRequired keys; for internal records prefer dataclasses.
4. Validate external input into these types at the boundary (a schema library or explicit checks), then rely on the types inside.
5. Handle every member explicitly where the difference matters; avoid else branches that hide new members.

Expected result

Adding a state or key produces checker errors at every place that must handle it; serialisation uses the declared values.

Limits and test basis

Hints do not validate at run time; boundary validation is still required. Very large enumerations belong in data, not code. Mechanics follow the cited documentation.