[Python-Dev] Investigating time for `import requests`

Koos Zevenhoven k7hoven at gmail.com
Tue Oct 3 05:58:05 EDT 2017

I've probably missed a lot of this discussion, but this lazy import
discussion confuses me. We already have both eager import (import at the
top of the file), and lazy import (import right before use).

The former is good when you know you need the module, and the latter is
good when you having the overhead at first use is preferable over having
the overhead at startup. But like Raymond was saying, this is of course
especially relevant when that import is likely never used.

Maybe the fact that the latter is not recommended gives people the feeling
that we don't have lazy imports, although we do.

What we *don't* have, however, is *partially* lazy imports and partially
executed code, something like:

on demand:
    class Foo:
        # a lot of stuff here

    def foo_function(my_foo, bar):
        # more stuff here

When executed, the `on demand` block would only keep track of which names
are being bound to (here, "Foo" and "foo_function"), and on the lookup of
those names in the namespace, the code would actually be run.

Then you could also do

on demand:
    import sometimes_needed_module


on demand:
    from . import all, submodules, of, this, package

This would of course drift away from "namespaces are simply dicts". But who
cares, if they still provide the dict interface. See e.g. this example with
automatic lazy imports:


Another thing we *don't* have is unimporting. What if I know that I'm only
going to need some particular module in this one initialization function.
Why should I keep it in memory for the whole lifetime of the program?


+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171003/d7fe75b3/attachment.html>

More information about the Python-Dev mailing list