PEP 3147 - new .pyc format

Steven D'Aprano steve at
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> 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 

       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
       Python 2.5c2: 62131 (fix wrong code: for x, in ... in 

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?


More information about the Python-list mailing list