Lazy imports and PEP 649

[Liz (Elizabeth King)]

@Daverball

I would like to lazy import every single type I only use inside annotations. There are linter plugins which enforce this style, while the win may be small in most cases, when it’s spread across thousands of imports in hundreds of source files it will eventually add up. As a bonus you will be confronted with cyclic dependencies less frequently.

So your cyclic dependency issue becomes a problem that only gets seen by runtime introspection tools rather than you fixing it. Deferring an import won’t solve a cyclic dependency, you just make it only visible to runtime annotation users, and you’re advocating using it everywhere, making the problem prolific for them.

[antonagestam]

That sounds like a mischaracterization. Seeing fewer issues caused by circular dependencies is a side effect of allowing type-only imports, but as mentioned previously in this thread, it is not the only motivation for them.

[Liz (Elizabeth King)]

If the imports need to be resolved at runtime, they need to be resolvable without a circular dependency. deferring them doesn’t get rid of this requirement without also changing import semantics in a larger way.

[mikeshardmind (Michael H)]

Just for reference, runtime resolvability and cyclic imports are a known thing, and the current “best practice” involves not having a circular import even within TYPE_CHECKING

Using get_type_hints() with cyclic imports

This probably isn’t the answer you were hoping for, but… I recommend against using TYPE_CHECKING conditionals to work around cyclical imports even for static typing. It may seem like a convenient and expedient solution, but it’s masking a deeper structural problem in your code. If you have cyclical imports, that means your code is not well layered, and your code should be refactored. If you’re using pyright as a type checker, you can enable the reportImportCycles check to report any import cyc…

Not much else to add, this topic is retreading ground other people have covered in multiple ways, and there’s good reasons why lazy importing wasn’t accepted in general, why those who have a need for it have advocated not over-using it (see the lazy_loader from scientific python linked above), and that this shouldn’t be used as a bandaid over design issues so that they have less visibility.

[Daverball (David Salvisberg)]

Not necessarily, since the import is delayed, the circular dependency may now no longer be a circular dependency, since both modules have already been fully initialized, so it depends on at which point the runtime introspection happens. Granted, that this scenario is far less likely when using from __future__ import annotations.

But I really shouldn’t have even pointed out the thing about cyclic dependencies, because it’s a pure aside. I care about the runtime overhead. I’m perfectly happy to keep using if TYPE_CHECKING for this and use linters to help me determine when I actually do need one of those imports at runtime, but it would be nicer if those linters didn’t need special casing for pydantic models and the like, because the imports could still be resolved at runtime when needed.

[alicederyn (Alice)]

Thank you to everyone who has educated me in this conversation. My personal takeaway is:

• We do not need any Python changes
• I certainly won’t be writing module getattrs
• I will be a lot happier using “from future import annotations” and turning on Ruff’s auto-typing-only-import rule now!

I don’t think any existing runtime type checkers will even look up my runtime library types (except @singledispatch and I know on what that is likely to be used), and I think any hypothetical future library can find typing imports via the AST if it needs to.