[Python-Dev] requirements for moving __import__ over to importlib?

[Nick Coghlan]

On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 2/7/2012 9:35 PM, PJ Eby wrote:
>>  It's just that not everything I write can depend on Importing.
>> Throw an equivalent into the stdlib, though, and I guess I wouldn't have
>> to worry about dependencies...
>
> And that is what I think (agree?) should be done to counteract the likely
> slowdown from using importlib.

Yeah, this is one frequently reinvented wheel that could definitely do
with a standard implementation. Christian Heimes made an initial
attempt at such a thing years ago with PEP 369, but an importlib based
__import__ would let the implementation largely be pure Python (with
all the increase in power and flexibility that implies).

I'm not sure such an addition would help much with the base
interpreter start up time though - most of the modules we bring in are
because we're actually using them for some reason.

The other thing that shouldn't be underrated here is the value in
making the builtin import system PEP 302 compliant from a
*documentation* perspective. I've made occasional attempts at fully
documenting the import system over the years, and I always end up
giving up because the combination of the pre-PEP 302 builtin
mechanisms in import.c and the PEP 302 compliant mechanisms for things
like zipimport just degenerate into a mess of special cases that are
impossible to justify beyond "nobody got around to fixing this yet".
The fact that we have an undocumented PEP 302 based reimplementation
of imports squirrelled away in pkgutil to make pkgutil and runpy work
is sheer insanity (replacing *that* with importlib might actually be a
good first step towards full integration).

Cheers,
Nick.

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