10.04.18 18:58, Antoine Pitrou пише:
On Tue, 10 Apr 2018 18:49:36 +0300 Serhiy Storchaka email@example.com wrote:
- 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  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.  The part of issue33041 backported to 3.7 and 3.6 is an other example.  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.