* Steven D'Aprano:
On Sat, 30 Jan 2010 18:40:42 -0800, Paul Rubin wrote:
Ben Finney <ben+pyt...@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?
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.
:-)
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
