Type annotations in `_colorize` module are unresolvable at runtime

[gotmax23]

Bug 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

[hugovk]

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 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: Theme

[DavidCEllis]

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.