PEP 641 – Using an underscore in the version portion of Python 3.10 compatibility tags

PEP: 641
Title: Using an underscore in the version portion of Python 3.10 compatibility tags
Author: Brett Cannon <brett at python.org>, Steve Dower <steve.dower at python.org>, Barry Warsaw <barry at python.org>
PEP-Delegate: Pablo Galindo <pablogsal at 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
Created: 20-Oct-2020
Python-Version: 3.10
Post-History: 2020-10-21
Resolution: https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags/5513/42

Abstract
Motivation
Rationale
Specification
Backwards Compatibility
Security Implications
How to Teach This
Reference Implementation
Rejected Ideas
- Not making the change
Open Issues
- How far should we take this?
- Standardizing on double digit minor version numbers
References
Copyright

Abstract

注解

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 2 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 1 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.