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

Nick Coghlan ncoghlan at gmail.com
Fri Feb 10 01:22:01 CET 2012

On Fri, Feb 10, 2012 at 1:05 AM, Brett Cannon <brett at python.org> wrote:

This would then be similar to the way main.c already works when it interacts with runpy - simple cases are handled directly in C, more complex cases get handed over to the Python module. I suspect that if people want the case where you load from bytecode is fast then this will have to expand beyond this to include C functions and/or classes which can be used as accelerators; while this accelerates the common case of sys.modules, this (probably) won't make Antoine happy enough for importing a small module from bytecode (importing large modules like decimal are already fast enough).

No, my suggestion of keeping a de minimis C implementation for the builtin import is purely about ensuring the case of repeated imports (especially those nested inside functions) remains as fast as it is today.

To speed up first time imports (regardless of their origin), I think it makes a lot more sense to use better algorithms at the importlib level, and that's much easier in Python than it is in C. It's not like we've ever been philosophically opposed to smarter approaches, it's just that import.c was already hairy enough and we had grave doubts about messing with it too much (I still have immense respect for the effort that Victor put in to sorting out most of its problems with Unicode handling). Not having that millstone hanging around our necks should open up lots of avenues for improvement without breaking backwards compatibility (since we can really do what we like, so long as the PEP 302 APIs are still invoked in the right order and the various public APIs remain backwards compatible).

Cheers, Nick.

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

More information about the Python-Dev mailing list