Re: [Python-Dev] Investigating time for `import requests`
On Mon, Oct 2, 2017, 12:30 Barry Warsaw, wrote: > On Oct 2, 2017, at 14:56, Brett Cannon 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. > My approach supports global "switch" to make it transparent (see the notebook for details). I'm just saying you could also support a function for lazy importing when you have only a module or two you to be lazy about while being eager otherwise. -Brett > -Barry > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Investigating time for `import requests`
On Mon, Oct 2, 2017, 13:56 Antoine Pitrou, wrote: > On Mon, 02 Oct 2017 18:56:15 + > Brett Cannon 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). > > Do they? I was under the impression they had their own home-baked, > GPL-licensed, lazy-loading __import__ re-implementation. > > At least they used to, perhaps they switched to something else > (probably still GPL-licensed, though). > Their Python 3 port wraps the stdlib code in their old API (they showed me the code at PyCon US). So the GPL bit is for API adapting. -Brett > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Investigating time for `import requests`
On Mon, Oct 2, 2017, 17:49 Ronald Oussoren, wrote: > Op 3 okt. 2017 om 04:29 heeft Barry Warsaw het > volgende geschreven: > > > On Oct 2, 2017, at 14:56, Brett Cannon 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. -Brett > Ronald > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)
On Wed, Oct 4, 2017, 09:00 Antoine Pitrou, wrote: > On Wed, 4 Oct 2017 10:14:22 -0400 > Barry Warsaw wrote: > > On Oct 3, 2017, at 13:29, Benjamin Peterson wrote: > > > > > I'm not sure turning the implementation details of our internal formats > > > into APIs is the way to go. > > > > I still think an API in the stdlib would be useful and appropriate, but > it’s not like this couldn’t be done as a 3rd party module. > > It can also be an implementation-specific API for which we don't > guarantee anything in the future. The consenting adults rule would > apply. > I've toyed with the idea of coming up with an API for bytecode files, but having lived through the last file format change I could never come up with one that didn't just chop off the header or would be a maintenance burden. But having an API that followed just what was in that Python release like the ast module would solve that problem. Then 3rd-party code could wrap it it smooth out differences between versions. -Brett > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
