Repository navigation
Type annotations in _colorize module are unresolvable at runtime #150994
Description
Activity
The trivial fix in "Easy Fixes: If Only Buggy People Were This Easy to Fix" (beartype/beartype#656 (comment)):
# This obviously useless "if" conditional... if False: from typing import IO, Literal, Self, ClassVar _theme: Theme # <-- no idea what this is all about. smells fishy # ...should instead be a proper PEP 810 lazy import: lazy from typing import IO, Literal, Self, ClassVar # ...while preserving this smelly fishy code, because someone will yell if we don't: if False: _theme: Theme # <-- preserved. but still smells fishy
means the
typingmodule still ends up eagerly imported, due to theLiteral.This prevents an eager
typingimport and fixes the reproducer:lazy from typing import IO, Self, ClassVar # types if False: from typing import Literal _theme: Theme
This leaves us with a new reproducer of:
from annotationlib import get_annotations from _colorize import LiveProfiler get_annotations(LiveProfiler)
I'm not sure if this will also trip up beartype. One mildly sneaky thought is to put a lazy import at the end of the module after the dataclasses have done their work.
Also this technically fails in Python 3.14 too, earlier Python used
__future__annotations so technically won't suffer from theget_annotationsissue.This PR might help: #149992 (though I haven't tested the issue's specific repro).
That would probably help for analysing
_pyrepl. I didn't look too closely but I think that will probably always end up importingtypingwithout further changes anyway?I don't think we can do the same thing for
_colorizeas it doesn't importtypingbut has aLiteralin an annotation that would cause the import to be triggered by dataclasses.If we do want to resolve this, other than putting the import at the end, we could potentially 'hide' the
Literalin a type alias that should preventtypingfrom being imported when@dataclassgets the annotations. Though that would break ifdataclassesever started looking inside type aliases.Ah, right,
_colorizenot_pyrepl. I opened #151018 because the fix seemed easy and makes the code mostly nicer anyway.beartype though should use the FORWARDREF format if it expects to call get_type_hints on arbitrary objects.
I think beartype might be using
FORWARDREFbut at some point later it is attempting to resolve the refs? I see calls to.evaluate()raising in the long log that was posted on the beartype issue.- added a commit that references this issue
on Sep 10, 2026
Bug report
Bug description:
See the above reproducer and beartype/beartype#656 for more context. The issue here is that the
_colorizemodule (which is imported by other public modules/packages in the stdlib) guards itstypingimports (which are used in dataclass field annotations) in anif False:block. This breaks runtime type checkers like beartype that introspect type annotations at runtime.CPython versions tested on:
3.15
Operating systems tested on:
Linux
Linked PRs