[Import-SIG] Proposal for a lazy-loading finder

[Nick Coghlan]

On 12 July 2017 at 02:50, Brett Cannon <brett at python.org> wrote:
> On Mon, 10 Jul 2017 at 18:55 Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Those could even just be recipes in the documentation rather than
>> actual standard library functions.
>
> Possibly. The first two are rather simple and should be obvious for anyone
> wanting to use lazy loading (there will continue to be a warning in the docs
> that you should only use lazy loading if you know what you're doing).

Right, I only added them to help make it clearer which parts of the
prefix-matching ones were related to the prefix matching, and which
were related to the callback interface. Without the
as-simple-as-possible examples as a point of comparison, I think the
prefix matching examples are harder to follow than they need to be.

>> > And I purposefully didn't do a prefix match for ensure_eager as it's
>> > only
>> > meant for specific modules that have some try/except block which fails
>> > in
>> > the face of lazy loading. And since that should be a per-module thing
>> > instead of a per-package thing I don't want it over-extending. Plus
>> > providing a callback solution lets people engineer their own prefix
>> > matching
>> > solution if that's what they need.
>>
>> Yep, that's why I like Antoine's callback suggestion.
>
> So are you suggesting dropping even the ensure_eager convenience argument?

Aye, I think so - the filter is pretty trivial to write, especially
since you can even hardcode the blacklist or just put it in a module
global:

    _ALWAYS_EAGER = set("module1 module2 module3 module4".split())
    def _lazy_loading_filter(fullname):
        return fullname not in _ALWAYS_EAGER

It's also easy enough to add a convenience shortcut for that later if
we decide we really want to, while if we start with one, then we
introduce a bit of an awkward transition from simple module
blacklisting to arbitrary filtering when learning the API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia