In issue 25483 I'm adding an opcode to make f-string formatting more
robust and faster. As part of that, I'm bumping the .pyc magic number.
While doing that, I notice Lib/importlib/_bootstrap_external.h includes
this comment:
# Starting with the adoption of PEP 3147 in Python 3.2, every bump in magic
# number also includes a new "magic tag", i.e. a human readable string used
# to represent the magic number in __pycache__ directories. When you change
# the magic number, you must also set a new unique magic tag. Generally
this
# can be named after the Python major version of the magic number bump, but
# it can really be anything, as long as it's different than anything else
# that's come before. The tags are included in the following table,
starting
# with Python 3.2a0.
The "following table" is a comment, that contains a few references to
the tag "cpython-<version>", specifically cpython-32. It doesn't seem
that the tag is routinely updated in the comment.
sys.implementation.cache_tag returns 'cpython-36', and is in fact
implemented as 'cpython-{PY_MAJOR_VERSION}{PY_MINOR_VERSION}'.
Do I need to do anything else? Unlike what the comment in
_boostrap_external.py suggests, this "magic tag" will not change every
time a bytecode is added, but only on every minor release. Which implies
that if we have a micro release that adds an opcode, we'll in fact break
the promise in the comment.
>From my understanding on how this tag is used, this wouldn't be a
problem (because the magic number in the file also changes). But I want
to make sure I'm not misunderstanding something. I think the comment
above is probably just misleading.
Eric.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4