On Fri, 20 Oct 2017 at 06:42 Ronald Oussoren <ronaldousso...@mac.com> wrote:
> Op 10 okt. 2017 om 01:48 heeft Brett Cannon <br...@python.org> het > volgende geschreven: > > > > On Mon, Oct 2, 2017, 17:49 Ronald Oussoren, <ronaldousso...@mac.com> > wrote: > >> Op 3 okt. 2017 om 04:29 heeft Barry Warsaw <ba...@python.org> het >> volgende geschreven: >> >> > On Oct 2, 2017, at 14:56, Brett Cannon <br...@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? > Generally, but provide out of the box a blacklist that already contains troublesome modules in the stdlib. > In the latter case this would still not be backward compatible. > Correct, which is why it would be opt-in and projects would need to be diligent in keeping up their blacklist.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com