iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 2026: Note `PY_VERSION_HEX` changes needed for 3.YYYY (#3995)

This commit is contained in:
Hugo van Kemenade 2024-09-25 17:34:23 -07:00 committed by GitHub
parent 9c9c5c3aee
commit 2a3dfe0c88
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
peps/pep-2026.rst
View File

@ -532,8 +532,24 @@ However, YY.MM versioning is rejected for many of the same reasons as YY.0 versi
For example, Python 3.2026 would be released in 2026.
It's clearer that the minor version is a year when using a four digits, and
avoids confusion with Ubuntu versions which use YY.MM. However, this is
rejected as changing from two to four digits would break more code than 3.YY versioning.
avoids confusion with Ubuntu versions which use YY.MM.
``PY_VERSION_HEX``
''''''''''''''''''
CPython's C API :external+python:c:macro:`PY_VERSION_HEX` macro currently uses
eight bits to encode the minor version, accommodating a maximum minor version of
255. To hold a four-digit year, it would need to be expanded to 11 bits to fit
2047 or rather 12 bits for 4095.
This looks feasible, as it's intended for numeric comparisons, such as
``#if PY_VERSION_HEX >= ...``. In the `top 8,000 PyPI projects
<https://dev.to/hugovk/how-to-search-5000-python-projects-31gk>`__
only one instance was found of bit shifting
(``hexversion >> 16 != PY_VERSION_HEX >> 16``).
However, 3.YYYY is rejected as changing from two to four digits would
nevertheless need more work and break more code than simpler 3.YY versioning.
Editions
--------