gh-148406: Fix annotations of _colorize.FancyCompleter

[danielhollas]

Fixes #148406, using an approach suggested in the issue.

Test plan

Before

>>> import _colorize, pprint
>>> pprint.pprint(_colorize.FancyCompleter.__annotations__)
{'NoneType': '\x1b[1;32m',
 'bool': '\x1b[1;32m',
 'builtin_function_or_method': '\x1b[1;32m',
 'bytes': '\x1b[1;32m',
 'complex': '\x1b[1;32m',
 'float': '\x1b[1;32m',
 'function': '\x1b[1;32m',
 'int': '\x1b[1;32m',
 'method': '\x1b[1;32m',
 'method_descriptor': '\x1b[1;32m',
 'method_wrapper': '\x1b[1;32m',
 'module': '\x1b[1;32m',
 'str': '\x1b[1;32m',
 'type': '\x1b[1;32m',
 'wrapper_descriptor': '\x1b[1;32m'}

After

>>> from _colorize import FancyCompleter
>>> from pprint import pprint
>>> pprint(FancyCompleter.__annotations__)
{'NoneType': <class 'str'>,
 'bool': <class 'str'>,
 'builtin_function_or_method': <class 'str'>,
 'bytes': <class 'str'>,
 'complex': <class 'str'>,
 'float': <class 'str'>,
 'function': <class 'str'>,
 'int': <class 'str'>,
 'method': <class 'str'>,
 'method_descriptor': <class 'str'>,
 'method_wrapper': <class 'str'>,
 'module': <class 'str'>,
 'str': <class 'str'>,
 'type': <class 'str'>,
 'wrapper_descriptor': <class 'str'>}

Also added a regression tests to ensure that re module is not imported during _colorize import.
We've just made re import lazy in dataclasses (#148379), but because of the bug resolved here, it ended up being imported (because the annotations were strings, which was triggering the path that uses the re module).

• Issue: Annotations of _colorize.FancyCompleter dataclass are funky #148406

[danielhollas]

This is a change in a private module that should not be user facing so I don't think blurb is needed?

[picnixz]

Can we just do from builtins import str as _str? it may be a bit easier to read then.

[danielhollas]

we could, but I kind of like the explicitness of the current solution. But if others agree I am happy to change it

[picnixz]

I'm also good with that. I just know that in other modules we also have _str = builtins.str or _int = builtins.int. I'll let Hugo decide (I just find the repetition of builtins.str a bit less readable but that's my opinion)

[danielhollas]

Ah, if it is already a pattern elsewhere then I am more okay with that. Will wait for others to chime in before changing.

[sobolevn]

One more idea: there's a special section for type imports in if False: right below. Maybe you should utilize it?

[DavidCEllis]

One more idea: there's a special section for type imports in if False: right below. Maybe you should utilize it?

I think that's only worth doing if the import is slow (so for typing it makes sense), otherwise you're just making the runtime annotations worse which will technically make the dataclass construction ever so slightly slower as get_annotations now has to build a bunch of ForwardRef objects¹.

Footnotes

1. I'm not sure if this would be measurable in context in _colorize ↩