How does typing.get_type_hints resolve a class's hints differently from a function's?

## One namespace versus one namespace per class For a function the model is simple: the annotations belong to that function, and they are evaluated against `func.__globals__`, the module dict where the `def` appeared. One set of annotations, one namespace. A class is a hierarchy, and `typing.get_type_hints` treats it as one. It iterates `cls.__mro__` in reverse — from `object` down to the class you asked about — and for each entry it collects that class's *own* annotations and evaluates them against the globals of the module where **that** class was defined, obtained from `sys.modules` via the class's `__module__`. Each round updates the accumulating dict, so a subclass that re-annotates an inherited attribute overwrites the base's entry, matching the attribute-lookup semantics a reader expects. The class's own namespace is also available while resolving its annotations, so a helper class defined inside the class body can be named in an annotation there. ## Consequence one: inherited hints appear `cls.__annotations__` is own-annotations-only. A subclass that declares nothing gets an empty dict, not its parent's. That is deliberate: before 3.10, an un-annotated class would appear to have its base's annotations purely through ordinary attribute lookup, which produced a famous class of bugs in code that iterated a class's fields. In 3.10 classes and modules gained a lazily-created empty annotations dict so that access no longer falls through to a base. So if you want "every annotated attribute this class has, including inherited ones", `get_type_hints(cls)` is the API, and reading `__annotations__` in a loop over the MRO is you re-implementing it — usually without the per-class globals, which is where the hand-rolled version breaks. ## Consequence two: each base resolves in its own module This is the part that stops being academic the moment you inherit from a class you did not write. Suppose a base class declares an attribute annotated with a name that only its own module imports, perhaps quoted, perhaps a forward reference. If resolution used *your* module's globals, subclassing it would fail unless you imported names you have no reason to know about. Because each class's annotations are evaluated in its defining module, the base resolves with its own imports and your subclass resolves with yours, and neither leaks into the other. The same rule explains a failure people find surprising: if a base's annotation names something under a guarded import in *its* module, no amount of importing that name in your module fixes it, because your globals are never consulted for that base's entries. ## What is not included Methods. `get_type_hints(cls)` returns the class-body attribute annotations, not the signatures of the functions defined in the body — those are annotations *of the functions*, and you get them by calling `get_type_hints` on the method. Likewise, an attribute assigned in `__init__` without an annotation in the class body is invisible to this API, because there is no annotation to resolve; runtime attribute discovery is a different problem. Entries wrapped in `ClassVar` are returned as-is, wrapper included; deciding what `ClassVar` means for your consumer is your job, not the resolver's. `Annotated` metadata is stripped unless you pass `include_extras=True`, exactly as for a function. ## Practical guidance This merge is why so much runtime machinery — record types, schema builders, injection containers, serializers — is built on class annotations rather than on instance inspection: one call gives you the complete, resolved, inheritance-aware picture of the declared attributes. Two cautions. First, cost: resolving a deep hierarchy evaluates every base's annotations on every call, and nothing is cached, so do it once when the class is registered rather than per instance. Second, ordering: the returned dict is in MRO-merge order, base entries first, with a re-annotated name keeping the position it first appeared at while taking the derived value. If your consumer cares about declaration order — a positional constructor, a serialized field order — do not assume it matches the subclass body's order, and pin the ordering you need explicitly rather than inheriting whatever the merge produced. Finally, remember what you are asking for. `get_type_hints(cls)` answers "what are the declared attribute types of this class, resolved". It does not answer "what attributes will an instance have", and treating the two as the same is how a serializer ends up silently dropping everything that was set dynamically.