How does moving an import under if TYPE_CHECKING: break an import cycle?

### What actually goes wrong in a cycle Importing a module runs it top to bottom, and the partially built module object is registered in `sys.modules` before that run finishes. Say a payment reconciliation job has `ledger.py` and `reconciler.py`, and each has a module-level import of the other. Whichever is imported first begins executing, hits its import of the second, and the second begins executing; when the second reaches its import of the first, the first is already in `sys.modules` but only half built. `import ledger` succeeds and gives back a module missing most of its names; `from ledger import Ledger` fails outright with an `ImportError` whose message mentions a partially initialised module. The failure therefore depends on import order and on which import form you used, which is why cycles feel intermittent. ### The typing-only edge is not a real edge Cycles that appear during typing adoption usually have an asymmetry. `reconciler.py` genuinely constructs and calls a `Ledger`. `ledger.py` does not use the reconciler at all — it only wants to name the class in a signature. That second direction is a documentation dependency masquerading as a code dependency, and it is the one to cut: ```python # ledger.py from typing import TYPE_CHECKING if TYPE_CHECKING: from reconciler import Reconciler class Ledger: def attach(self, reconciler: "Reconciler") -> None: self.reconciler = reconciler ``` At runtime `ledger` no longer imports `reconciler`, so the graph is acyclic and import order stops mattering. The checker still analyses the guarded block, so `Reconciler` resolves and `attach` keeps its real signature. Nothing is weakened for analysis; only the runtime edge disappears. ### Keeping the annotation unevaluated The guarded name is not bound at runtime, so the annotation must not be evaluated when the class body executes. From 3.14, PEP 649 makes annotations lazily evaluated by default: they are compiled into a separate function that runs only if something asks for them, so the plain unquoted form is safe on import. On 3.13 and earlier the annotation was evaluated at definition time unless the module carried `from __future__ import annotations` (3.7, PEP 563) or the hint was written as a string. Libraries supporting older floors still add the future import for exactly this reason. What has never been lazy is everything outside annotation position. If `ledger.py` wanted `class Ledger(Reconciler)`, or applied a decorator from the other module, or wrote `Alias = Reconciler` at module level, or called `cast(Reconciler, x)` with the class unquoted, the name is evaluated as the module loads and you get a `NameError` instead of a cycle. Trading one import-time crash for another is not progress; those cases mean the dependency is real. ### When the cycle is genuine If both modules call into each other at runtime, hiding an import removes an edge nobody was traversing and fixes nothing. Three honest fixes exist. Extract the shared piece into a third module both import, which usually reveals that the cycle was a missing abstraction. Invert one direction behind a small interface, so the lower-level module depends on a protocol rather than on the concrete class. Or move the import inside the function that needs it, so it executes after both modules have finished initialising — cheap, since a repeat import is a `sys.modules` lookup, but it hides the dependency from readers and from anything that scans the import graph, so use it sparingly. ### What still breaks after the fix The module now imports cleanly, but the guarded name remains absent at runtime. Anything that resolves the annotation later — a framework that inspects a signature to build validation or injection, a serializer that reads hints — searches the module namespace and does not find the class. That failure appears wherever the inspection happens, not at import, so it can survive into a running service. If a module must support hint resolution, the class has to be reachable at runtime, and the cycle has to be fixed structurally instead. ### How to talk about it in an interview Name the mechanism, not the ritual: half-initialised modules in `sys.modules`, a typing-only edge that is not a dependency, a checker that reads the branch the interpreter skips, and lazy annotations that keep the hint from being evaluated. Then say the limit out loud — the guard is a fix for false edges, not a cure for tangled design.