Fix local_annotations() ignoring the stop= MRO boundary

[wbarnha]

Description

Severity: breaks every faust.Record subclass constructor, on every supported Python version — introduced by e8d0a96 ("Support Python 3.13, drop Python 3.8"), currently blocking essentially all faust-streaming/faust CI.

>>> import faust
>>> class Foo(faust.Record):
...     x: int
>>> Foo(x=1)
TypeError: __outer__.<locals>.__init__() missing 1 required positional argument: '__evaluated_fields__'

Root cause #1 — local_annotations() ignoring the stop= MRO boundary

annotations(cls, stop=...) is documented to only consider fields declared between stop (exclusive) and cls (inclusive) in the MRO — callers rely on this to exclude internal bookkeeping attributes declared on a base class above stop (e.g. faust.Record passes stop=Record to exclude its internal ModelT/Model bases).

local_annotations(cls) resolved fields via typing.get_type_hints(cls, ...), which always merges annotations from the entire real MRO regardless of stop. iter_mro_reversed() correctly bounds which classes get scanned, but get_type_hints() on any one of them independently re-walks the full ancestry, defeating the boundary. A non-ClassVar annotation on an excluded base — faust.types.models.ModelT.__evaluated_fields__, sitting right next to the correctly-filtered ClassVar-marked __is_model__ — leaked back in as if it were a real field of every subclass, becoming a required positional parameter of every generated __init__.

Fix: local_annotations() now reads a class's own annotations via inspect.get_annotations(cls) (with a same-behavior backport for the 3.9 floor, since it was added in 3.10) instead of get_type_hints. This has no MRO fallback at all — strictly safer than the boundary get_type_hints() defeated.

Root cause #2 — found via CI's actual Python 3.14 runner, not in this repo's control

Fixing #1 alone still crashed on Python 3.14 CI (a different, pre-existing latent bug this investigation surfaced): every field with a string-quoted annotation (e.g. foo: "int") crashed with

AttributeError: 'ForwardRef' object has no attribute '__forward_evaluated__'.

eval_type() unconditionally routed every ForwardRef through _ForwardRef_safe_eval(), a hand-rolled evaluator reading ForwardRef's private __forward_evaluated__/__forward_code__/__forward_value__ attributes — by its own comment, a workaround for "3.6/3.7". mode's floor is Python 3.9, so this path was already dead weight for the versions it targeted, and Python 3.14 no longer exposes those attributes on ForwardRef at all, turning dead weight into a hard crash.

Fix: removed _ForwardRef_safe_eval (and the now-unused _type_check import). typing._eval_type — already called unconditionally right below the removed code — resolves ForwardRef instances directly and is the same stdlib function typing.get_type_hints() itself relies on, so it always matches whichever ForwardRef implementation the running interpreter actually has.

No 3.14 interpreter was available in this development environment (network policy blocks python-build-standalone/deadsnakes, no Docker daemon) — root cause #2 was diagnosed from real 3.14 CI output via a temporary diagnostic test (since removed), not guessed.

Verification

• Added test_annotations__stop_excludes_base_above_stop, a regression test mirroring the ModelT scenario (root cause Pass loop attribute to asyncio.ensure_future #1). Confirmed it fails with the pre-fix code and passes with the fix.
• Existing test_annotations, test_annotations__skip_classvar, and test_annotations__no_local_ns_raises already exercise string-quoted forward refs, so they cover root cause Rename package and fix configuration files #2 without needing a new dedicated test.
• Full suite: 736 passed on Python 3.11 and 3.13, ruff clean.
• Cross-checked against a real faust-streaming/faust checkout with this fixed mode installed in place of the PyPI release: Foo(x=1, name="hi") instantiates correctly and Foo._options.fields has no __evaluated_fields__ leak.
• CI's Python 3.14 job is the authoritative check for root cause Rename package and fix configuration files #2, since no local 3.14 interpreter was available.

Known residual issue — not fully resolved by this PR

Independent of both fixes above, faust's tests/functional/test_models.py still has an estimated ~11 failures involving related/polymorphic model field coercion (test_custom_coercion, test_polymorphic_fields, test_Secret, test_default_no_blessed_key, and others), down from total collection failure for the whole file beforehand. This looks like a narrower, separate issue — possibly other fallout from e8d0a96 — and needs further investigation before considering faust's model test suite fully green again. (Not independently re-verified in this environment due to an unrelated pytest-version/conftest mismatch when running faust's own suite here.)

🤖 Generated with Claude Code

https://claude.ai/code/session_01HgnKFtXZbCjXNoVNWa5JLd