Brett Cannon <br...@python.org> added the comment:

So here is the deal with PyImport_ExecCodeModuleObject(): bootstrapping and 
Barry has made this a little annoying. =)

First off, PyImport_ImportFrozenModuleObject() uses 
PyImport_ExecCodeModuleObject(), so that precludes just directly importing imp 
to handle this function entirely. OK, so that means just trying to chop out the 
path manipulation stuff since that is duplicating code found in imp/importlib.

The problem, though, is that PyImport_ExecCodeModuleWithPathnames() will take 
its pathname argument and try to get a source path from it if it points to some 
.pyc file (PEP 3147 or sourceless .pyc, and if that new path exists then it is 
used instead of the given path. Unfortunately that API was introduced in Python 
3.2, so there is a backwards-compatibility issue in that one can't just rip out 
the code w/o supporting it. But those semantics are the reason the equivalent 
of imp.source_from_cache() continues to exist in Python/import.c.

I see two options here. One is to simply leave the C code in, but that has the 
drawback of duplicated Python and C code. Two is to stick in a call to 
imp.source_from_cache() between PyImport_ExecCodeModuleWithPathnames() and 
PyImport_ExecCodeModuleObject() so the former retains the semantics and the 
latter doesn't pick up the bad habit before 3.3 is released.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13959>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to