"import type" statement to replace typing.TYPE_CHECKING idiom and fix circular references

[bschubert (Brian Schubert)]

Some related previous discussions:

Add a `import type` feature (like typescript)

Lazy imports and PEP 649

With PEP 649 impending, I have some concerns that the tension between static-only and runtime type annotations may get worse. Specifically: there is tooling that automatically moves typing-only imports behind an if TYPE_CHECKING guard, which uses from __future__ import annotations as a “trigger”; this determining of intent will no longer be possible as a library author, I am torn between keeping import times fast by hiding my annotation imports behind a guard, versus allowing runtime reflectio…

PEP 690: Lazy Imports Again

After a lot of engagement in our previous discussion topic about Lazy Imports (with over two hundred comments!), I’m presenting an updated proposal of PEP 690 - Lazy Imports. We have (hopefully) considered and addressed each and all of the suggestions in the previous discussion thread, by either providing rejection reasons or improving the API and implementation. Some examples of things we’ve modified are: a per-module opt-in, specifically designed to address some use cases in Scientific Python…

Fall back to the typing.* namespace in lazy hint contexts

With PEP 649 impending, I wanted to float this idea. Adding types to a Python code-base requires importing many names from the typing module. After a while it’s natural to start pondering whether some of the more common ones couldn’t be made builtins. However, adding builtins is not something that can be done lightly, and I would expect to see exactly zero progress should that idea be seriously proposed. Still, it seems a bit silly that the following program requires an import. from typing im…