GeezerVison is showing github.com — Type annotations in `_colorize` module are unresolvable at runtime · Issue #150994 · python/cpython
Type annotations in _colorize module are unresolvable at runtime #150994DescriptionBug report
Bug description:
from annotationlib import get_annotations
from _colorize import ThemeSection
get_annotations(ThemeSection) # NameError: name 'ClassVar' is not defined See the above reproducer and beartype/beartype#656 for more context. The issue here is that the _colorize module (which is imported by other public modules/packages in the stdlib) guards its typing imports (which are used in dataclass field annotations) in an if 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
Activityhugovk commented on Jun 6, 2026 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 fishymeans the typing module still ends up eagerly imported, due to the Literal.
This prevents an eager typing import and fixes the reproducer:
lazy from typing import IO, Self, ClassVar
# types
if False:
from typing import Literal
_theme: ThemeDavidCEllis commented on Jun 6, 2026 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 the get_annotations issue. JelleZijlstra commented on Jun 6, 2026 DavidCEllis commented on Jun 6, 2026 JelleZijlstra commented on Jun 6, 2026 This PR might help: #149992 (though I haven't tested the issue's specific repro). DavidCEllis commented on Jun 6, 2026 That would probably help for analysing _pyrepl. I didn't look too closely but I think that will probably always end up importing typing without further changes anyway?
I don't think we can do the same thing for _colorize as it doesn't import typing but has a Literal in 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 Literal in a type alias that should prevent typing from being imported when @dataclass gets the annotations. Though that would break if dataclasses ever started looking inside type aliases. JelleZijlstra commented on Jun 6, 2026 Ah, right, _colorize not _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. DavidCEllis commented on Jun 6, 2026 I think beartype might be using FORWARDREF but 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.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|