On Wed, Feb 8, 2012 at 11:09, Antoine Pitrou <solip...@pitrou.net> wrote:
> Le mercredi 08 février 2012 à 11:01 -0500, Brett Cannon a écrit : > > > > > > On Tue, Feb 7, 2012 at 17:42, Antoine Pitrou <solip...@pitrou.net> > > wrote: > > On Tue, 7 Feb 2012 17:24:21 -0500 > > Brett Cannon <br...@python.org> wrote: > > > > > > IOW you want the sys.modules case fast, which I will never > > be able to match > > > compared to C code since that is pure execution with no I/O. > > > > > > Why wouldn't continue using C code for that? It's trivial > > (just a dict > > lookup). > > > > > > Sure, but it's all the code between the function call and hitting > > sys.modules which would also need to get shoved into the C code. As I > > said, I have not tried to optimize anything yet (and unfortunately a > > lot of the upfront costs are over stupid things like checking if > > __import__ is being called with a string for the module name). > > I guess my point was: why is there a function call in that case? The > "import" statement could look up sys.modules directly. > Because people like to do wacky stuff with their imports and so fully bypassing __import__ would be bad. > Or the built-in __import__ could still be written in C, and only defer > to importlib when the module isn't found in sys.modules. > Practicality beats purity. It's a possibility, although that would require every function call to fetch the PyInterpreterState to get at the cached __import__ (so the proper sys and imp modules are used) and I don't know how expensive that would be (probably as not as expensive as calling out to Python code but I'm thinking out loud).
_______________________________________________ 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
