This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brett.cannon
Recipients Arfrever, berker.peksag, brett.cannon, eric.araujo, eric.snow, meador.inge, pitrou, python-dev
Date 2012-04-29.19:38:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2012-04-29 19:38:21brett.cannonsetrecipients: + brett.cannon, pitrou, eric.araujo, Arfrever, meador.inge, python-dev, eric.snow, berker.peksag
2012-04-29 19:38:21brett.cannonsetmessageid: <>
2012-04-29 19:38:21brett.cannonlinkissue13959 messages
2012-04-29 19:38:21brett.cannoncreate