[Python-Dev] importing .pyc-files generated by Python 1.5.2 in Python 1.6. Why not? (original) (raw)

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