PEP 3147 - new .pyc format

[Alf P. Steinbach]

* 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 
> 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