10.04.18 18:58, Antoine Pitrou пише:
On Tue, 10 Apr 2018 18:49:36 +0300
Serhiy Storchaka <storch...@gmail.com>
wrote:
3. The number of compatible subversion. Currently the interpreter
supports only a single magic number. If the updated version of the
compiler produces more optimal or more correct but compatible bytecode
(like ), there is no way to say that the new bytecode is preferable, but
the old bytecode can be used too. Changing the magic number causes
invalidating all pyc files compiled by the old compiler (see [4] for the
example of problems caused by this). The header could contain two magic
numbers: the major magic number should be bumped for incompatible
changes, the minor magic number should be reset to 0 when the major
magic number is bumped, and should be bumped when the compiler become
producing different but compatible bytecode.
-1. This is a risky move (and costly, in maintenance terms). It's easy
to overlook subtle differencies that may translate into
incompatibilities in some production uses. The rule « one Python
feature release == one bytecode version » is easy to remember and
understand, and is generally very well accepted.
A bugfix release can fix bugs in bytecode generation. See for example
issue27286. [1] The part of issue33041 backported to 3.7 and 3.6 is an
other example. [2] There were other examples of compatible changing the
bytecode. Without bumping the magic number these fixes can just not have
any effect if existing pyc files were generated by older compilers. But
bumping the magic number in a bugfix release can lead to rebuilding
every pyc file (even unaffected by the fix) in distributives.
[1] https://bugs.python.org/issue27286
[2] https://bugs.python.org/issue33041
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
