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

[Ronald Oussoren]

Op 10 okt. 2017 om 01:48 heeft Brett Cannon <brett at python.org <mailto:brett at python.org>> het volgende geschreven:

> 
> 
> On Mon, Oct 2, 2017, 17:49 Ronald Oussoren, <ronaldoussoren at mac.com <mailto:ronaldoussoren at mac.com>> wrote:
> Op 3 okt. 2017 om 04:29 heeft Barry Warsaw <barry at python.org <mailto:barry at python.org>> het volgende geschreven:
> 
> > On Oct 2, 2017, at 14:56, Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> >
> >> So Mercurial specifically is an odd duck because they already do lazy importing (in fact they are using the lazy loading support from importlib). In terms of all of this discussion of tweaking import to be lazy, I think the best approach would be providing an opt-in solution that CLI tools can turn on ASAP while the default stays eager. That way everyone gets what they want while the stdlib provides a shared solution that's maintained alongside import itself to make sure it functions appropriately.
> >
> > The problem I think is that to get full benefit of lazy loading, it has to be turned on globally for bare ‘import’ statements.  A typical application has tons of dependencies and all those libraries are also doing module global imports, so unless lazy loading somehow covers them, it’ll be an incomplete gain.  But of course it’ll take forever for all your dependencies to use whatever new API we come up with, and if it’s not as convenient to write as ‘import foo’ then I suspect it won’t much catch on anyway.
> >
> 
> One thing to keep in mind is that imports can have important side-effects. Turning every import statement into a lazy import will not be backward compatible.
> 
> Yep, and that's a lesson Mercurial shared with me at PyCon US this year. My planned approach has a blacklist for modules to only load eagerly.

I’m not sure if i understand. Do you want to turn on lazy loading for the stdlib only (with a blacklist for modules that won’t work that way), or generally? In the latter case this would still not be backward compatible. 

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171020/dc769968/attachment.html>