On Sat, 24 Jun 2017 16:28:29 +0000
Brett Cannon <brett(a)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 ;-)