The issue is that some imports can be made lazy and some cannot. A binaristic all-or-nothing approach does not address the issue. What if we have a program where on feature works only when lazy imports are enabled and one feature only when lazy imports are disabled? This scenario may sound ridiculous, but it is surprisingly easy to write a program that exhibits this behavior, especially in a large codebase.

My point is that many things _will_ break if migrated to lazy imports. Whether they should have been written in Python in the first place is a separate question that isn’t relevant to this discussion.

Theoretically the implementation may use the approach "as lazy as possible". Traverse lazy imports until you encounter a regular one. I doubt it will make much difference, but at least it gives an option.

Maybe the package that requires lazy can somehow declare that requirement, so another package that tries to force not lazy will fail early and realize it needs to replace this dependency with something compatible or change its ways. It definitely adds complexity, though.

Or check at runtime if it's running with the lazy import feature active. Then instead of breaking in mysterious ways in production it would crash on startup, during development.