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

[Brett Cannon]

On Fri, 20 Oct 2017 at 06:42 Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> Op 10 okt. 2017 om 01:48 heeft Brett Cannon <brett at python.org> het
> volgende geschreven:
>
>
>
> On Mon, Oct 2, 2017, 17:49 Ronald Oussoren, <ronaldoussoren at mac.com>
> wrote:
>
>> Op 3 okt. 2017 om 04:29 heeft Barry Warsaw <barry at python.org> het
>> volgende geschreven:
>>
>> > On Oct 2, 2017, at 14:56, Brett Cannon <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?
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171020/4bfe8d5e/attachment.html>