From my understanding on how this tag is used, this wouldn't be a
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. 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.
On Oct 28, 2015, at 08:35 AM, Eric V. Smith wrote:
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.
IIRC, it used to have to be changed in the code, but with this...
sys.implementation.cache_tag returns 'cpython-36', and is in fact implemented as 'cpython-{PY_MAJOR_VERSION}{PY_MINOR_VERSION}'.
...I don't believe it does any more.
Do I need to do anything else?
I don't think so.
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.
Right. Have we ever done that though? We shouldn't!
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.
Yeah, it's just out of date. Cheers, -Barry
On Wed, Oct 28, 2015 at 6:35 AM, Eric V. Smith <eric@trueblade.com> wrote:
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.
You will want to bump the number on the following line: https://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap_external... -eric
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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail...
On 10/28/2015 10:19 AM, Barry Warsaw wrote:
On Oct 28, 2015, at 08:35 AM, Eric V. Smith wrote:
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.
IIRC, it used to have to be changed in the code, but with this...
sys.implementation.cache_tag returns 'cpython-36', and is in fact implemented as 'cpython-{PY_MAJOR_VERSION}{PY_MINOR_VERSION}'.
...I don't believe it does any more.
Okay. Maybe I'll update that comment, then.
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.
Right. Have we ever done that though? We shouldn't!
And maybe I'll add that to the updated comment! Eric.
On 10/28/2015 10:22 AM, Eric Snow wrote:
On Wed, Oct 28, 2015 at 6:35 AM, Eric V. Smith <eric@trueblade.com> wrote:
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.
You will want to bump the number on the following line: https://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap_external...
Thanks. That part I've done (but forgot to mention). I was just concerned about the "magic tag" part, which Barry cleared up. Eric.
participants (3)
-
Barry Warsaw -
Eric Snow -
Eric V. Smith