PEP 641 – Using an underscore in the version portion of Python 3.10 compatibility tags
- Using an underscore in the version portion of Python 3.10 compatibility tags
- Brett Cannon <brett at python.org>, Steve Dower <steve.dower at python.org>, Barry Warsaw <barry at python.org>
- Pablo Galindo <pablogsal at python.org>
- Standards Track
This PEP was rejected due to potential breakage in the community.
Using the tag system outlined in PEP 425 (primarily used for wheel
file names), each release of Python specifies compatibility tags
py39 for CPython 3.9). For CPython 3.10, this PEP
3_10 as the version portion of the tags
Up to this point, the version portion of compatibility tags used in
e.g. wheel file names has been a straight concatenation of the major
and minor versions of Python, both for the CPython interpreter tag and
the generic, interpreter-agnostic interpreter tag (e.g.
py39, respectively). This also applies to the ABI tag
cp39). Thanks to both the major and minor versions being
single digits, it has been unambiguous what which digit in e.g.
But starting with Python 3.10, ambiguity comes up as
310 does not
clearly delineate whether the Python version is
310 as the major-only version of Python. Thus using
separate major/minor portions as allowed by PEP 425 disambiguates
the Python version being supported.
3_10 instead of another proposed separator is a restriction
of PEP 425, thus the only options are
SOABI configure variable and
sysconfig.get_config_var('py_version_nodot') will be updated to
Tools relying on the ‘packaging’ project  already expect a
version specification of
3_10 for Python 3.10. Keeping the version
310 would require backing that change out and
updating dependent projects (e.g. pip).
3_10 will impact any tools that implicitly rely on
the convention that the minor version is a single digit. However,
these are broken regardless of any change here.
For tools assuming the major version is only the first digit, they
will require updating if we switch to
In non-locale ASCII,
_ sorts after any digit, so lexicographic
sorting matching a sort by Python version of a wheel file name will be
Since PEP 515 (Python 3.6), underscores in numeric literals are ignored.
This means that
int("310") produce the same result,
and ordering based on conversion to an integer will be preserved.
However, this is still a bad way to sort tags, and the point is raised
here simply to show that this proposal does not make things worse.
There are no known security concerns.
How to Teach This
As use of the interpreter tag is mostly machine-based and this PEP disambiguates, there should not be any special teaching consideration required.
A pull request  already exists adding support to CPython 3.10. Support for reading wheel files with this proposed PEP is already implemented.
Not making the change
It was considered to not change the tag and stay with
argument was it’s less work and it won’t break any existing
tooling. But in the end it was thought that the disambiguation is
better to have.
How far should we take this?
Other places where the major and minor version are used could be
updated to use an underscore as well (e.g.
.pyc files, the import
path to the zip file for the stdlib). It is not known how useful it
would be to make this pervasive.
Standardizing on double digit minor version numbers
An alternative suggestion has been made to disambiguate where the
major and minor versions start/stop by forcing the minor version to
always be two digits, padding with a
0 as required. The advantages
of this is it makes the current
cp310 interpreter tag accurate,
thus minimizing breakage. It also does differentiate going forward.
There are a couple of drawbacks, though. One is the disambiguation
only exists if you know that the minor version number is two digits;
compare that to
cp3_10 which is unambiguous regardless of your
base knowledge. The potential for a three digit minor version number
is also not addressed by this two digit requirement.
There is also the issue of other interpreters not following the
practice in the past, present, or future. For instance, it is
unknown if other people have used a three digit version portion of the
interpreter tag previously for another interpreter where this rule
would be incorrect. This change would also suggest that interpreters which
currently have a single digit minor version – e.g. PyPy 7.3 – to
pp703 or make the switch from their next
minor release onward (e.g. 7.4 or 8.0). Otherwise this would make this
rule exclusive to the
cp interpreter type which would make it more
confusing for people.
- Reference implementation (https://github.com/python/cpython/pull/20333)
- The ‘packaging’ project (https://pypi.org/project/packaging/)
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.
Last modified: 2022-03-09 16:04:44 GMT