What does the @override decorator from Python's typing module tell a static type checker?

## The failure it exists to catch Overriding in Python is name-based and resolved at run time. A subclass method overrides a base method only because the two happen to share a name; there is no declaration linking them. So if the base method is renamed, or moved, or misspelled in the subclass in the first place, the subclass method does not become an error — it becomes **a new method that nothing calls**. The base implementation quietly takes over for every call made through the base's name, and the subclass keeps a chunk of dead code that looks live. This is a nasty class of bug because it is invisible to everything cheap. The module still imports. The class still instantiates. A large regression pack — say 340 cases — only catches it if some case actually drives the renamed behaviour through that particular subclass, and a subclass that exists to specialise one rare path usually has no such case. The failure surfaces later as "the caching layer stopped caching" or "the specialised formatting is gone", far from the rename that caused it. ## What PEP 698 added Python 3.12 added `typing.override` (PEP 698). You apply it to a method in a subclass: ```python from typing import override class CachingGeocoder(Geocoder): @override def lookup(self, address: str) -> str: ... ``` The decorator is a **declaration of intent** aimed at static analysis. A type checker looks at the decorated method and asks whether any base class of the enclosing class declares a member with that name. If none does, it reports an error at the decorated definition — exactly where the reader can fix it. The check is purely about the name existing on a base; the checker's normal compatibility rules for the signature are applied to every override anyway, decorated or not. The direction of the guarantee matters. `@override` says "this must be overriding something". It does **not** say "nothing may override this" — that is `typing.final`, a different decorator solving the opposite problem. And it does not say "the base must be abstract": an abstract base already gives you a different error (instantiating a class that has not implemented everything abstract), which is why abstract hierarchies feel safer and concrete ones need `@override` most. ## Run-time behaviour At run time the decorator is close to a no-op. It returns the same object it was given, and best-effort sets a marker attribute on it so that runtime introspection tools can tell the method was declared as an override; if the object refuses attribute assignment — some descriptors and C-level callables do — it swallows the failure and returns the object anyway. It never inspects the class, because when the decorator runs the class body has not finished executing and the base classes are not its business. Nothing raises. A method decorated with it that overrides nothing behaves at run time exactly as if the decorator were absent. That is the standard trade in Python's typing story: the standard library ships the vocabulary, the checker supplies the enforcement, and the interpreter stays out of it. If you never run a checker, `@override` buys you documentation and nothing more. ## Using it in practice It is opt-in per method, which means an unmarked override is not itself an error — a hierarchy where only half the overrides carry the marker gets only half the protection. Checkers therefore offer a strictness option that flags any method overriding a base member without the marker; turning that on is what converts the feature from decoration into a real invariant. The usual rollout is: enable the option, let the checker enumerate every override in the hierarchy, add the decorator mechanically, and from then on any base-class rename produces a wall of errors at exactly the subclasses that need editing. On Python 3.11 and earlier the name is not in `typing`; it is available only from the typing backport distribution. If your code must run on both, import it from the backport and the semantics are identical, since the whole feature is a checker convention plus an inert decorator. Two boundaries worth keeping straight in an interview. First, `@override` is not Java's `@Override`: Python's has no compile step to enforce it, so its power is exactly the strictness of the checker you run. Second, it is a *name* check, not a *behaviour* check — an override that keeps the name but breaks the base's contract is caught (if at all) by the signature-compatibility rules, not by this decorator.