Where does Python store a variable annotation written inside a function body?

## Three scopes, three behaviours PEP 526 gave Python variable annotations — `name: SomeType` with or without a value — and the storage rules differ by where you write them. Interviewers use this to check that you know annotations are a compile-time artefact whose runtime footprint is deliberately small. ### Function locals: not stored, not even evaluated ```python def run_billing(): rate: Undefined = 0.2 return rate run_billing() # 0.2 — no error run_billing.__annotations__ # {} — parameters and return only ``` `Undefined` is not a name that exists anywhere, and nothing complains, because the annotation on a local variable is never evaluated. There is no dict of local annotations either — not on the function, not on the frame. The information exists in the source for a type checker to read, and nowhere else at runtime. There is one runtime effect, and it is the part candidates miss. An annotated name is still a *binding target* as far as the compiler is concerned, so it becomes local to the function even with no value assigned: ```python total = 100 def report(): total: int # no value — but `total` is now local return total # UnboundLocalError, not 100 ``` ### Class bodies: stored, but no attribute is created ```python class Invoice: total: float currency: str = "EUR" Invoice.__annotations__ # {'total': float, 'currency': str} Invoice.total # AttributeError Invoice.currency # 'EUR' ``` The annotation is recorded; the attribute is created only by the assignment. This is exactly the distinction that class-building machinery relies on: a decorator that turns a class into a record type reads the annotations to learn the field names and their order, and reads the class attributes to learn which fields have defaults. A bare `total: float` therefore means *a required field*, and `currency: str = "EUR"` means *a field with a default* — and none of that is enforcement, only construction. ### Module level: stored on the module A module-level `due: float` goes into the module's `__annotations__` dict. Read it through the module object: ```python import sys due: float sys.modules[__name__].__annotations__ # {'due': float} ``` On Python 3.14 the dict is materialised on first access rather than being built as the module executes, so reach for it as an attribute of the module object rather than expecting a bare global name to already be bound. ## Why the asymmetry exists The design trade is cost versus usefulness. Class and module annotations are genuinely consulted at runtime — record-building decorators, serialization helpers and introspection tools all walk them — so paying for a dict is worth it. Local annotations have no plausible runtime consumer: locals are not addressable from outside the frame, and the frame is gone when the call returns. Storing them would cost time and memory on every call for information nothing could use, so Python stores nothing. ## What to say in the interview State the three scopes and the two surprises: **a local annotation is not evaluated, so a bogus name in one never fails**, and **a class-body annotation without a value creates no attribute**. Add the `UnboundLocalError` consequence if you want to show you know why the compiler still cares about a statement it does not execute. If you are asked to prove any of it, `__annotations__` on the function, on the class and on the module object is the whole demonstration — and the emptiness of the function's copy is the proof for locals.