diff --git a/peps/pep-0011.rst b/peps/pep-0011.rst index 16002dd539f..9c2e60f9fe3 100644 --- a/peps/pep-0011.rst +++ b/peps/pep-0011.rst @@ -9,6 +9,7 @@ Post-History: `18-Aug-2007 `__, `20-Feb-2015 `__, `10-Mar-2022 `__, + `21-Nov-2025 `__, Abstract @@ -35,15 +36,20 @@ 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 CPython as well as providing a -procedure to remove code for platforms with few or no CPython -users. +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 lists what platforms *are* supported by the CPython -interpreter. This lets people know what platforms are directly -supported by the CPython development team. +This PEP also explicitly lists what platforms are directly +*supported* by the CPython development team. Support tiers @@ -135,17 +141,43 @@ x86_64-unknown-freebsd BSD libc, clang Victor Stinner ================================ =========================== ======== -All other platforms -------------------- +Unsupported 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 encouraged to notify people +listed in the `Platforms experts list`_ in the CPython contributor's guide, +to review any submitted fixes (if unobtrusive), and to consider adding +configuration or extension capabilities necessary for workarounds. + +People interested in unsupported platforms may add themselves to the +`Platforms experts list`_ to request that they be notified on issues +related to "their" platform. +There is, however, no formal guarantee that they *will* be notified. -Support for a platform may be partial within the code base, such as -from active development around platform support or accidentally. -Code changes to platforms not listed in the above tiers may be rejected -or removed from the code base without a deprecation process if they -cause a maintenance burden or obstruct general improvements. +.. _Platforms experts list: https://devguide.python.org/core-team/experts/#platforms -Platforms not listed here may be supported by the wider Python -community in some way. If your desired platform is not listed above, +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. @@ -207,6 +239,27 @@ source tree 3 years after the extended support for the compiler has ended (but continue to remain available in revision control). +POSIX +''''' + +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 POSIX 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. + + Legacy C Locale ''''''''''''''' @@ -373,6 +426,9 @@ No-longer-supported platforms Discussions =========== +* November 2025: `Policy for unsupported platforms + `_ + (Petr Viktorin) * April 2022: `Consider adding a Tier 3 to tiered platform support `_ (Victor Stinner)