[Python-Dev] How to interpret get_code from PEP 302?

Guido van Rossum guido at python.org
Tue Aug 21 06:10:16 CEST 2007


On 8/20/07, Brett Cannon <brett at python.org> wrote:
> PEP 302 ("New Import Hooks") has an optional extensions section so
> that tools like py2exe and py2app have an easier time.  Part of the
> optional extensions is the method get_code that is to return the code
> object for the specified method (if the loader can handle it).
>
> But there is a lack in the definition of how get_code is supposed to
> be implemented.  The definition says that the "method should return
> the code object associated with the module", which is fine.  But then
> it goes on to state that "If the loader doesn't have the code object
> but it _does_ have the source code, it should return the compiled
> source code".  This throws me as this makes it sound like bytecode
> does not need to be used if the loader does not already have a code
> object and there is no source to be had; any bytecode can be ignored.
>
> Now I doubt this is how it is supposed to be read.  Does anyone
> disagree with that?  If not, I will change the wording to mention that
> bytecode must be used if no source is available (and that the magic
> number must be verified).

The only reading that makes sense is that it should always return a
code object (i.e. always byte code) and thet it can either get the
byte code by unmarshaling the equivalent of a .pyc file (after
skipping the first 8 bytes) *or* by calling compile() on the source
code. So, in the specific case of a zip file, it should first look for
a .pyc file, and then for a .py file. This is the opposite of how
things work on the filesystem, where it first looks for a .py, and
then for a .pyc; if both exist, the .pyc is only used if its mtime
matches the timestamp in the .pyc header. (But why am I explaining
this to you? :-) The idea for zip files is that quick loading is
preferred, and that the source is only used if no .pyc is found at all
(or whatever convention is used). This makes it easier to have a zip
that contains both .py and .pyc files -- the .py files are only used
for reference (e.g. one could imagine using them for tracebacks).

But maybe I'm missing a subtlety in your description of the issue?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list