PEP696 + PEP749: Defer evaluation of defaults when parametrizing

[randolf-scholz]

Bug report

Bug description:

With PEP 696 + PEP 749, the following works just fine:

class Scalar[CompatT, TruthT = BoolScalar]: ...
class BoolScalar(Scalar): ...
class IntScalar(Scalar[int]): ...  # OK ✅️

However, if we switch around the order of definition, the code breaks:

class Scalar[CompatT, TruthT = BoolScalar]: ...
class IntScalar(Scalar[int]): ...  # ❌️ NameError: name 'BoolScalar' is not defined
class BoolScalar(Scalar): ...

I guess since the default gets evaluated here. Not sure whether this is a bug or feature request, but it would be nice if the evaluation of the default could be deferred in is case as well.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

[sabasiddique1]

Hi! I’d like to work on this issue and share the direction I’m considering.

It appears that the default type parameter is evaluated eagerly during specialization (e.g. Scalar[int]), which raises NameError if the default (BoolScalar) isn’t defined yet. Since annotation evaluation already supports deferred forward‑reference handling, it seems reasonable for type parameter defaults to follow the same mechanism.

Proposed approach:

• In typevar_default_for_subst, evaluate the default using annotationlib.call_evaluate_function(..., Format.FORWARDREF) instead of direct evaluation.
• This should allow forward references in defaults to resolve correctly while preserving the existing caching behavior of __default__.

Regression test:

class Scalar[CompatT, TruthT = BoolScalar]: ...
class IntScalar(Scalar[int]): ...  # should work
class BoolScalar(Scalar): ...

If this aligns with the intended semantics of PEP 696/749, I’d be happy to prepare a PR.