PEP: 641 Title: Using an underscore in the version portion of Python
3.10 compatibility tags Author: Brett Cannon <brett@python.org>, Steve
Dower <steve.dower@python.org>, Barry Warsaw <barry@python.org>
PEP-Delegate: Pablo Galindo <pablogsal@python.org> Discussions-To:
https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags/5513
Status: Rejected Type: Standards Track Content-Type: text/x-rst Created:
20-Oct-2020 Python-Version: 3.10 Post-History: 21-Oct-2020 Resolution:
https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags/5513/42

Abstract

Note

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 (e.g. cp39,
py39 for CPython 3.9). For CPython 3.10, this PEP proposes using 3_10 as
the version portion of the tags (instead of 310).

Motivation

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. cp39 and py39,
respectively). This also applies to the ABI tag (e.g. cp39). Thanks to
both the major and minor versions being single digits, it has been
unambiguous what which digit in e.g. 39 represented.

But starting with Python 3.10, ambiguity comes up as 310 does not
clearly delineate whether the Python version is 3.10, 31.0, or 310 as
the major-only version of Python. Thus using 3_10 to separate
major/minor portions as allowed by PEP 425 disambiguates the Python
version being supported.

Rationale

Using 3_10 instead of another proposed separator is a restriction of PEP
425, thus the only options are 3_10 or 310.

Specification

The SOABI configure variable and
sysconfig.get_config_var('py_version_nodot') will be updated to use 3_10
appropriately.

Backwards Compatibility

Tools relying on the 'packaging' project[1] already expect a version
specification of 3_10 for Python 3.10. Keeping the version specifier as
310 would require backing that change out and updating dependent
projects (e.g. pip).

Switching to 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 3_10.

In non-locale ASCII, _ sorts after any digit, so lexicographic sorting
matching a sort by Python version of a wheel file name will be kept.

Since PEP 515 (Python 3.6), underscores in numeric literals are ignored.
This means that int("3_10") and 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.

Security Implications

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.

Reference Implementation

A pull request[2] already exists adding support to CPython 3.10. Support
for reading wheel files with this proposed PEP is already implemented.

Rejected Ideas

Not making the change

It was considered to not change the tag and stay with 310. The 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.

Open Issues

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 change from pp73 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.

References

Copyright

This document is placed in the public domain or under the
CC0-1.0-Universal license, whichever is more permissive.



  Local Variables: mode: indented-text indent-tabs-mode: nil
  sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

[1] The 'packaging' project (https://pypi.org/project/packaging/)

[2] Reference implementation
(https://github.com/python/cpython/pull/20333)