I think the question of what this would mean for libraries has been a bit vague in this thread, and would benefit from more concrete examples. Specifically, I don’t think the idea of libraries “opting themselves in” to lazy imports, which has been mentioned a few times, is actually relevant or helpful to the real use cases I’m aware of.
If we consider a library like click or pydantic, the typical case is that the library provides a registration decorator or a base class, and application developers will apply this decorator or subclass from this base class in their own code. This means that whether the library opts in to its own modules being lazily imported is beside the point. The library provides a utility which has the potential to add import side effects to a few of the application developer’s own modules, which may require explicit eager importing for the side effects to occur in time. So the application developer, who is choosing to explicitly enable lazy imports for their application to make it start up faster, may have to also eagerly import one or two of their own modules; all of this is in their control.
So I don’t think we need the complicated set of controls that @zrothberg proposed. I don’t see practical problems solved by that complexity that aren’t already addressable with a global opt-in and a per-module opt-out controlled by the application developer, which is what the PEP already proposes.
If anyone is aware of a library that relies on import side effects within its own code such that lazy import of the library’s own modules would break the library, I’d be interested to take a look at that case!
For a little context on prevalence in practice, the Instagram Server codebase is multiple million lines of code, uses lazy imports applied globally, and has precisely five modules opted out.