Why is a forward reference in a Python annotation written as a quoted string?

## The problem quoting solves An annotation is an expression, and an expression that mentions a name needs that name to be bound by the time it is evaluated. Two everyday situations violate that: - A method that returns its own class. Inside `class Ledger:`, the name `Ledger` is not bound until the whole `class` statement finishes, so `def merge(self, other: Ledger) -> Ledger` mentions a name that does not exist yet. - A function annotated with a class defined further down the module, or with a class that only a type checker will ever see. Quoting the annotation — `other: "Ledger"` — sidesteps the lookup entirely. A string literal is just a string: there is nothing to resolve, so nothing can fail. ## What ends up stored The string is stored verbatim. It is not parsed, not resolved, not converted into the class object: ```python class Ledger: def merge(self, other: "Ledger") -> "Ledger": return self Ledger.merge.__annotations__ # {'other': 'Ledger', 'return': 'Ledger'} ``` That is the single most important detail to state in an interview: **a quoted annotation stays a string in `__annotations__`**. Turning it into the class object is a separate, explicit step that some tool has to perform. ## What a type checker sees A checker treats `x: "Ledger"` and `x: Ledger` identically. It parses the contents of the string as an expression and resolves it in the enclosing scope, using the whole module — including definitions that appear after the annotated line, which is why a forward reference is legal to a checker in the first place. A consequence worth knowing: a typo inside the quotes is still an error. Quotes hide the name from the *interpreter*, not from the checker. ## The version story, stated precisely Through **Python 3.13**, annotations were evaluated eagerly: the expressions ran while the `def` statement or the class body executed, so an unquoted forward reference raised `NameError` on import. Quoting was the fix, and `from __future__ import annotations` was the file-wide alternative. In **Python 3.14**, annotations are no longer evaluated at definition time; they are computed lazily, when something reads `__annotations__`. The practical effect on this material is direct: ```python class Node: children: list[Node] def clone(self) -> Node: return self ``` On 3.14 this class body executes fine unquoted, and reading `Node.clone.__annotations__` afterwards yields the real class object, because by then `Node` is bound. On 3.13 the same code raises `NameError` while the class body runs. ## So are quotes obsolete? No, for three reasons, and the interviewer usually wants at least two of them: 1. **Names that never exist at runtime.** If a class is imported only for the checker's benefit, and that import never executes, no amount of deferred evaluation will resolve it — reading the annotations raises `NameError` at that moment. A string is never read as a name at all. 2. **Older interpreters.** A library that must import on 3.13 or earlier still needs quotes for any forward reference. 3. **Keeping runtime consumers honest.** If a decorator or a runtime tool walks a class's annotations, a string tells you plainly that nothing has been resolved yet. ## Common mistakes Quoting only part of an annotation and getting the nesting wrong — `list["Ledger"]` is fine, `"list[Ledger]"` is also fine, mixing them inconsistently is merely noisy. Believing that the interpreter substitutes the class in later — it does not; the string stays a string. And assuming quotes silence the checker — they do not; a misspelled class name inside quotes is reported exactly as it would be unquoted.