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

[Nick Coghlan]

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