PEP 3147 - new .pyc format
Alf P. Steinbach
alfps at start.no
Sun Jan 31 04:44:18 CET 2010
* Steven D'Aprano:
> 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
> 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?
I don't know enough about Python yet to comment on your question, but, just an
idea: how about a human readable filename /with/ some bytecode version id (that
added id could be the magic number)?
I think that combo could serve both the human and machine needs, so to speak. :-)
More information about the Python-list