PEP 3147 - new .pyc format
Steven D'Aprano
steve at REMOVE-THIS-cybersource.com.au
Sat Jan 30 22:09:25 EST 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