Are Python type annotations enforced at runtime, and what does the interpreter do with them?

## What the syntax actually does Python lets you attach an expression to three things: a function parameter (`def charge(amount: float)`), a function's return (`-> bool`), and a variable binding (`rate: float = 0.2`). The interpreter treats that expression as **data about the code**, never as a constraint on it. There is no hidden `isinstance` call at the call boundary, no coercion, no warning. Passing a `str` where the annotation says `float` is not an error to CPython; it is an error only to a tool you chose to run. ## Where it is stored Function annotations land in the function object's `__annotations__` dict, keyed by parameter name, with the return annotation under the key `'return'`. Class-body and module-level variable annotations land in the class's or module's `__annotations__` dict, keyed by variable name. That dict is an ordinary mutable dict of ordinary objects — you can read it, and you can write to it. ```python def charge(amount: float, retries: int = 3) -> bool: return "not a bool" charge.__annotations__ # {'amount': <class 'float'>, 'retries': <class 'int'>, 'return': <class 'bool'>} ``` An annotation may be *any* expression, not only a type: `def f(x: "anything at all"): ...` is legal, and so is `def f(x: 1 + 1): ...`. The language does not care; a type checker does. ## Who does the enforcing Four kinds of consumer, and it is worth naming them separately in an interview: 1. **Static type checkers.** They read your source (not the running program) and report mismatches. They run in CI or your editor. If you never run one, annotations change nothing. 2. **Editors and tooling.** Completion, go-to-definition, refactoring accuracy. 3. **Stdlib consumers.** `dataclasses.dataclass` decides which class attributes are fields by reading the class's annotations; `typing.NamedTuple` does the same. Note what they do *not* do: a dataclass will happily store a `str` in a field annotated `float`. 4. **Runtime validation libraries.** A third-party validation library can build real validators from a model class's annotations — but the validation comes from that library's code, not from Python. ## Why interviewers ask it Because the failure mode is quiet and expensive. Take a subscription-billing job that runs for six hours every night. Some helper is annotated `-> Decimal` but a refactor made it return a `float`; a later step divides and rounds, and the totals drift by fractions of a cent across hundreds of thousands of line items. Nothing raised. The annotation was true when it was written and false when it shipped, and only a checker in CI, or an explicit conversion or validation at the boundary where the value enters the system, would have caught it. A candidate who believes the annotation itself is the guard will not add either. ## The practical corollary If you want a runtime failure, you must write one: convert or validate explicitly at the edges of your program (parsing input, reading a database row, receiving a payload) and let annotations plus a checker cover the interior. That split — static checking inside, real validation at the boundary — is the answer an interviewer is listening for. ## One version note Non-enforcement has been true since annotations existed, and variable annotations arrived in Python 3.6. What changed in **3.14** is only *when* the annotation expression is evaluated: annotations are now computed lazily, on first access to `__annotations__`, instead of at definition time. The dict you get back is the same, and enforcement is still nobody's job but yours.