Hi!
I’d like to expand the All other platforms section of PEP 11 (CPython platform support), to make it clear that we support and encourage efforts to bring Python to places where the core team can’t reach – but we can’t be responsible if things break there, and we can clean up cruft.
I’d also like to add a section on POSIX platforms.
The initial proposal text is below; I also have a pull request that might get updates.
What do you think?
cc @brettcannon
Rationale
[The small text is substantially unchanged]
Over time, the CPython source code has collected various pieces of platform-specific code, which, at some point in time, was considered necessary to use CPython on a specific platform. Without access to this platform, it is not possible to determine whether this code is still needed. As a result, this code may either break during CPython’s evolution, or it may become unnecessary as the platforms evolve as well.
Allowing these fragments to grow poses the risk of unmaintainability: without having experts for a large number of platforms, it is not possible to determine whether a certain change to the CPython source code will work on all supported platforms. To reduce this risk, this PEP specifies what is required for a platform to be considered supported by the CPython core team, as well as providing a procedure to remove code for platforms with few or no CPython users.
On the other hand, allowing these fragments in the main repository can promote collaboration, can help identify non-portable parts of the code base, and is necessary for bootstrapping support for a “new” platform. This PEP specifies what it means for a platform to be “unsupported”, and how the core team handles code for such platforms.
This PEP also explicitly lists what platforms are directly supported by the CPython development team.
[…]
Unsupported platforms [instead of “All other platforms”]
All platforms not listed in the above tiers are unsupported by the core team. The core team does not develop and test on such platforms, and so they cannot provide any promises that Python will work on them.
However, the code base does include unsupported code – that is, code specific to unsupported platforms. Contributions in this area are welcome as long as they:
- pose a minimal maintenance burden to the core team, and
- benefit substantially more people than the contributor.
We assume contributors are able to maintain modifications/patches, test patched builds, redistribute modified code, make promises to their users, and otherwise support “their” platform. With that in mind, it is generally unnecessary to backport unsupported fixes to CPython’s maintenance branches.
Unsupported code that does cause a maintenance burden, or obstructs general improvements, may be rejected or removed from the code base without a deprecation process. Core team members that do this intentionally are expected to seek out and notify interested parties, to review any submitted fixes (if inobtrusive), and to consider adding configuration or extension capabilities necessary for workarounds.
People interested in unsupported platforms may add themselves to the Platforms experts list in the Cpython contributor’s guide to request that they be notified on issues related to “their” platform. There is, however, no formal guarantee that they will be notified.
Platforms not listed in this PEP may also be supported by the wider Python community in other ways. If your desired platform is not listed above, please perform a search online to see if someone is already providing support in some form.
[…]
POSIX [after “Windows”]
Features specified in POSIX are expected to work according to the standard. This cuts two ways:
-
If a POSIX feature is available, it is expected to conform to POSIX.
Workarounds for out-of-spec platforms are acceptable. For unsupported platforms, disabling functionality is preferred over a non-trivial workaround.
-
CPython should make no assumptions about these features beyond what’s specified in POSIX.
For example, while POSIX specifies errno as an int with no restrictions, error codes on all supported platforms happen to be positive. Relying on this would be considered a bug, even if it only manifests on unsupported platforms.