PEP 3147 - new .pyc format

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sun Jan 31 04:09:25 CET 2010


On Sat, 30 Jan 2010 18:40:42 -0800, Paul Rubin wrote:

> Ben Finney <ben+python at benfinney.id.au> writes:
>>>     0c4f0a0d.pyc # Python 3.1
>> Mapping magic numbers to versions is infeasible and will be incomplete:
>> Any mapping that exists in (say) Python 3.1 can't know in advance what
>> the magic number will be for Python 4.5.
> 
> But why do the filenames have magic numbers instead of version numbers?

The magic number changes with each incompatible change in the byte code 
format, which is not the same as each release. Selected values taken from 
import.c:

       Python 2.5a0: 62071
       Python 2.5a0: 62081 (ast-branch)
       Python 2.5a0: 62091 (with)
       Python 2.5a0: 62092 (changed WITH_CLEANUP opcode)
       Python 2.5b3: 62101 (fix wrong code: for x, in ...)
       Python 2.5b3: 62111 (fix wrong code: x += yield)
       Python 2.5c1: 62121 (fix wrong lnotab with for loops and
                            storing constants that should have been
                            removed)
       Python 2.5c2: 62131 (fix wrong code: for x, in ... in 
                            listcomp/genexp)


http://svn.python.org/view/python/trunk/Python/import.c?view=markup

The relationship between byte code magic number and release version 
number is not one-to-one. We could have, for the sake of the argument, 
releases 3.2.3 through 3.5.0 (say) all having the same byte codes. What 
version number should the .pyc file show?


-- 
Steven



More information about the Python-list mailing list