# "import type" statement to replace typing.TYPE\_CHECKING idiom and fix circular references

**URL:** <https://discuss.python.org/t/import-type-statement-to-replace-typing-type-checking-idiom-and-fix-circular-references/69518>\
**Category:** Typing\
**Tags:** typing\
**Created:** [October 29, 2024, 12:51am UTC](https://discuss.python.org/t/import-type-statement-to-replace-typing-type-checking-idiom-and-fix-circular-references/69518 "2024-10-29T00:51:29Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![bschubert](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bschubert/32/26920_2.png) [@bschubert](https://discuss.python.org/u/bschubert)\
**Post date:** [October 29, 2024, 1:08am UTC](https://discuss.python.org/t/import-type-statement-to-replace-typing-type-checking-idiom-and-fix-circular-references/69518/2 "2024-10-29T01:08:35Z")

</div>

Some related previous discussions:

> <https://github.com/python/typing/issues/928>
>
> Importing types can lead to circular imports, longer start up times and unwanted… side effects.
> 
> I want something like:
> \`\`\`py
> from foo.bar import type Baz
> 
> def foo(baz: Baz):
> print(baz.bat)
> \`\`\`
> Such that \`foo\`, \`foo.bar\` and \`foo.bar.Baz\` are not actually loaded at all.
> It could 'import' the symbol as a forward-ref or some type machinery thing. (maybe just the string "Baz")
> 
> \### Alternatives:
> \`\`\`py
> from \_\_future\_\_ import annotations
> 
> from typing import TYPE\_CHECKING
> if TYPE\_CHECKING:
> from foo.bar import Baz
> 
> def foo(baz: Baz):
> print(baz.bat)
> \`\`\`
> This is mega boilerplate, gross, and leads to messy wacky 'type-time' side effects (https://github.com/python/mypy/issues/11503).

> [@Lazy imports and PEP 649](https://discuss.python.org/t/lazy-imports-and-pep-649/48548):
>
> 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](https://discuss.python.org/t/pep-690-lazy-imports-again/19661):
>
> After a lot of engagement in our [previous discussion topic about Lazy Imports](https://discuss.python.org/t/pep-690-lazy-imports/15474) (with over two hundred comments!), I’m presenting an updated proposal of [PEP 690 - Lazy Imports](https://pep-previews.readthedocs.io/pep-0690/). 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](https://discuss.python.org/t/fall-back-to-the-typing-namespace-in-lazy-hint-contexts/48420):
>
> 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…

---

_[View the full topic](https://discuss.python.org/t/import-type-statement-to-replace-typing-type-checking-idiom-and-fix-circular-references/69518)._