PEP 2026: Note PY_VERSION_HEX changes needed for 3.YYYY

peps/pep-2026.rst

@@ -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
 --------