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

[Brett Cannon]

On Tue, Feb 7, 2012 at 22:47, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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'll see if I can come up with a pure Python way to handle setting
attributes on the module since that is the one case that my importers
project code can't handle.


> 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.
>

It wouldn't. This would be for third-parties only.


>
> 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).
>

I actually have never bothered to explain import as it is currently
implemented in any of my PyCon import talks precisely because it is such a
mess. It's just easier to explain from a PEP 302 perspective since you can
actually comprehend that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120208/c9ef5adc/attachment.html>