On Fri, Feb 10, 2012 at 1:05 AM, Brett Cannon <br...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com