On 21/02/2021 13.13, Victor Stinner wrote:
I propose to actively remove support for *legacy* platforms and architectures which are not supported by Python according to PEP 11 rules: hardware no longer sold and end-of-life operating systems. The removal should be discussed on a case by case basis, but I would like to get an agreement on the overall idea first. Hobbyists wanting to support these platforms/archs can continue to support them with patches maintained outside Python. For example, I consider that the 16-bit m68k architecture is legacy, whereas the OpenBSD platform is still actively maintained.
Python has different kinds of platform and architecture supports. In practice, I would say that we have:
- (1) Fully supported. Platform/architecture used by core developers
and have at least one working buildbot worker: fully supported. Since core developers want to use Python on their machine, they fix issues as soon as they notice them. Examples: x86-64 on Linux, Windows and macOS.
- (2) Best effort. Platform/architecture which has a buildbot worker
usually not used by core developers. Regressions (buildbot failures) are reported to bugs.python.org, if someone investigates and provides a fix, the fix is merged. But there is usually no "proactive" work to ensure that Python works "perfectly" on these platforms. Example: FreeBSD/x86-64.
- (3) Not (officially) supported. We enter the blurry grey area. There
is no buildbot worker, no core dev use it, but Python contains code specific to these platforms/architectures. Example: 16-bit m68k and 31-bit s390 architectures, OpenBSD.
The Rust programming language has 3 categories of Platform Support, the last one is :
(short reply, I'm heading out)
I'm +1 in general for your proposal. I also like the idea to adopt Rust's platform support definition.
For 3.10 I propose to add a configure option to guard builds on unsupported / unstable platforms. My draft PR https://github.com/python/cpython/pull/24610/commits/f8d2d56757a9cec7ae4dc72... implements a checker for unsupported platforms and adds a --enable-unstable-platforms flag. Configuration on unsupported platforms fails unless users explicitly opt-in.
The checker serves two purposes:
1) It gives users an opportunity to provide full PEP 11 support (buildbot, engineering time) for a platform. 2) It gives us the leverage to remove a flagged platform in the future or refuse support on BPO.