[Python-Dev] requirements for moving import over to importlib? (original) (raw)

Eric Snow ericsnowcurrently at gmail.com
Wed Feb 8 05:36:28 CET 2012

On Tue, Feb 7, 2012 at 8:47 PM, 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'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).

+1 on all counts

-eric

More information about the Python-Dev mailing list