On Sat, 24 Jun 2017 16:28:29 +0000 Brett Cannon <brett@python.org> wrote:
My experience is that:
- you want lazy imports to be implicit, i.e. they should work using the "import" statement and not any special syntax or function invocation
- you want a blacklist and/or whitelist mechanism to restrict lazy imports to a particular set of modules and packages, because some modules may not play well with lazy importing (e.g. anything that registers plugins, specializations -- think singledispatch --, etc.)
For example, I may want to register the "tornado", "asyncio" and "numpy" namespaces / packages for lazy importing, but not the "numba" namespace as it uses registration mechanisms quite heavily.
(and the stdlib could be part of the default lazy import whitelist)
That's all true for an end user's application, but for the stdlib where there is no knock-on effects from dependencies not being loaded lazily I don't think it's quite as critical. Plus lazy loading does make debugging harder by making loads that trigger an exception happen at the line of first use instead of at the import line, so I don't know if it's desirable to automatically make the whole stdlib be lazily loaded from the outset (which is what would be required since doing it in e.g. sitecustomize.py wouldn't happen until after startup anyway).
Yes, you are right. I was assuming that if we take the time to include a lazy import system, we'd make it available for third-party applications, though ;-)
Regards
Antoine.