[Python-Dev] importing .pyc-files generated by Python 1.5.2 in Python 1.6. Why not?
Peter Funk
pf@artcom-gmbh.de
Wed, 24 May 2000 23:34:19 +0200 (MEST)
[...about accepting 1.5.2 generated .pyc files...]
Guido van Rossum:
> Before accepting the trivial patch, I would like to see some analysis
> that shows that in fact all 1.5.2 .pyc files work correctly with 1.6.
Would it be sufficient, if a Python 1.6a2 interpreter executable containing
such a trivial patch is able to process the test suite in a 1.5.2 tree with
all the .py-files removed? But some list.append calls with multiple args
might cause errors.
> This means you have to prove that (a) the 1.5.2 marshal format is a
> subset of the 1.6 marshal format (easy enough probably) and (b) the
> 1.5.2 bytecode opcodes are a subset of the 1.6 bytecode opcodes. That
> one seems a little trickier; I don't remember if we moved opcodes or
> changed existing opcodes' semantics. You may be lucky, but it will
> cause an extra constraint on the evolution of the bytecode, so I'm
> somewhat reluctant.
I feel the byte code format is rather mature and future evolution
is unlikely to remove or move opcodes to new values or change the
semantics of existing opcodes in an incompatible way. As has been
shown, it is even possible to solve the 1/2 == 0.5 issue with
upward compatible extension of the format.
But I feel unable to provide a formal proof other than comparing
1.5.2/Include/opcode.h, 1.5.2/Python/marshal.c and import.c
with the 1.6 ones.
There are certainly others here on python-dev who can do better.
Christian?
BTW: import.c contains the following comment:
/* XXX Perhaps the magic number should be frozen and a version field
added to the .pyc file header? */
Judging from my decade long experience with exotic image and CAD data
formats I think this is always the way to go for binary data files.
Using this method newer versions of a program can always recognize
the file format version and convert files generated by older versions
in an appropriate way.
Regards, Peter