PEP: 11 Title: CPython platform support Author: Martin von Löwis
<martin@v.loewis.de>, Brett Cannon <brett@python.org> Status: Active
Type: Process Content-Type: text/x-rst Created: 07-Jul-2002
Post-History: 18-Aug-2007, 14-May-2014, 20-Feb-2015, 10-Mar-2022,

Abstract

This PEP documents how an operating system (platform) becomes supported
in CPython, what platforms are currently supported, and documents past
support.

Rationale

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 CPython as well as providing a procedure
to remove code for platforms with few or no CPython users.

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.

Support tiers

Platform support is broken down into tiers. Each tier comes with
different requirements which lead to different promises being made about
support.

To be promoted to a tier, steering council support is required and is
expected to be driven by team consensus. Demotion to a lower tier occurs
when the requirements of the current tier are no longer met for a
platform for an extended period of time based on the judgment of the
release manager or steering council. For platforms which no longer meet
the requirements of any tier by b1 of a new feature release, an
announcement will be made to warn the community of the pending removal
of support for the platform (e.g. in the b1 announcement). If the
platform is not brought into line for at least one of the tiers by the
first release candidate, it will be listed as unsupported in this PEP.

Tier 1

-   STATUS
-   CI failures block releases.
-   Changes which would break the main branch are not allowed to be
    merged; any breakage should be fixed or reverted immediately.
-   All core developers are responsible to keep main, and thus these
    platforms, working.
-   Failures on these platforms block a release.

  Target Triple              Notes
  -------------------------- -----------------
  aarch64-apple-darwin       clang
  i686-pc-windows-msvc       
  x86_64-pc-windows-msvc     
  x86_64-apple-darwin        BSD libc, clang
  x86_64-unknown-linux-gnu   glibc, gcc

Tier 2

-   STATUS
-   Must have a reliable buildbot.
-   At least two core developers are signed up to support the platform.
-   Changes which break any of these platforms are to be fixed or
    reverted within 24 hours.
-   Failures on these platforms block a release.

+-----------------------+--------------------+-----------------------+
| Target Triple         | Notes              | Contacts              |
+=======================+====================+=======================+
| aarc                  | glibc, gcc         | Petr Viktorin, Victor |
| h64-unknown-linux-gnu |                    | Stinner               |
|                       | glibc, clang       |                       |
|                       |                    | Victor Stinner,       |
|                       |                    | Gregory P. Smith      |
+-----------------------+--------------------+-----------------------+
| wasm32-unknown-wasi   | WASI SDK, Wasmtime | Brett Cannon, Eric    |
|                       |                    | Snow                  |
+-----------------------+--------------------+-----------------------+
| x86                   | glibc, clang       | Victor Stinner,       |
| _64-unknown-linux-gnu |                    | Gregory P. Smith      |
+-----------------------+--------------------+-----------------------+

Tier 3

-   STATUS
-   Must have a reliable buildbot.
-   At least one core developer is signed up to support the platform.
-   No response SLA to failures.
-   Failures on these platforms do not block a release.

+----------------------+----------------------+----------------------+
| Target Triple        | Notes                | Contacts             |
+======================+======================+======================+
| a                    |                      | Russell Keith-Magee, |
| arch64-linux-android |                      | Petr Viktorin        |
+----------------------+----------------------+----------------------+
| aar                  |                      | Steve Dower          |
| ch64-pc-windows-msvc |                      |                      |
+----------------------+----------------------+----------------------+
| arm64-apple-ios      | iOS on device        | Russell Keith-Magee, |
|                      |                      | Ned Deily            |
+----------------------+----------------------+----------------------+
| arm64                | iOS on M1 macOS      | Russell Keith-Magee, |
| -apple-ios-simulator | simulator            | Ned Deily            |
+----------------------+----------------------+----------------------+
| armv7l-unk           | Raspberry Pi OS,     | Gregory P. Smith     |
| nown-linux-gnueabihf | glibc, gcc           |                      |
+----------------------+----------------------+----------------------+
| powerpc64            | glibc, clang         | Victor Stinner       |
| le-unknown-linux-gnu |                      |                      |
|                      | glibc, gcc           | Victor Stinner       |
+----------------------+----------------------+----------------------+
| s39                  | glibc, gcc           | Victor Stinner       |
| 0x-unknown-linux-gnu |                      |                      |
+----------------------+----------------------+----------------------+
| x86_64-linux-android |                      | Russell Keith-Magee, |
|                      |                      | Petr Viktorin        |
+----------------------+----------------------+----------------------+
| x8                   | BSD libc, clang      | Victor Stinner       |
| 6_64-unknown-freebsd |                      |                      |
+----------------------+----------------------+----------------------+

All other platforms

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 not listed here may be supported by the wider Python community
in some way. If your desired platform is not listed above, please
perform a search online to see if someone is already providing support
in some form.

Notes

Microsoft Windows

Windows versions prior to Windows 10 follow Microsoft's Fixed Lifecycle
Policy, with a mainstream support phase for 5 years after release, where
the product is generally commercially available, and an additional 5
year extended support phase, where paid support is still available and
certain bug fixes are released. Extended Security Updates (ESU) is a
paid program available to high-volume enterprise customers as a "last
resort" option to receive certain security updates after extended
support ends. ESU is considered a distinct phase that follows the
expiration of extended support.

Windows 10 and later follow Microsoft's Modern Lifecycle Policy, which
varies per-product, per-version, per-edition and per-channel. Generally,
feature updates (1709, 22H2) occur every 6-12 months and are supported
for 18-36 months; Server and IoT editions, and LTSC channel releases are
supported for 5-10 years, and the latest feature release of a major
version (Windows 10, Windows 11) generally receives new updates for at
least 10 years following release. Microsoft's Windows Lifecycle FAQ has
more specific and up-to-date guidance.

CPython's Windows support currently follows Microsoft's lifecycles. A
new feature release X.Y.0 will support all Windows versions whose
extended support phase has not yet expired. Subsequent bug fix releases
will support the same Windows versions as the original feature release,
even if no longer supported by Microsoft. New versions of Windows
released while CPython is in maintenance mode may be supported at the
discretion of the core team and release manager.

As of 2024, our current interpretation of Microsoft's lifecycles is that
Windows for IoT and embedded systems is out of scope for new CPython
releases, as the intent of those is to avoid feature updates. Windows
Server will usually be the oldest version still receiving free security
fixes, and that will determine the earliest supported client release
with equivalent API version (which will usually be past its
end-of-life).

Each feature release is built by a specific version of Microsoft Visual
Studio. That version should have mainstream support when the release is
made. Developers of extension modules will generally need to use the
same Visual Studio release; they are concerned both with the
availability of the versions they need to use, and with keeping the zoo
of versions small. The CPython source tree will keep unmaintained build
files for older Visual Studio releases, for which patches will be
accepted. Such build files will be removed from the source tree 3 years
after the extended support for the compiler has ended (but continue to
remain available in revision control).

Legacy C Locale

Starting with CPython 3.7.0, *nix platforms are expected to provide at
least one of C.UTF-8 (full locale), C.utf8 (full locale) or UTF-8
(LC_CTYPE-only locale) as an alternative to the legacy C locale.

Any Unicode-related integration problems that occur only in the legacy C
locale and cannot be reproduced in an appropriately configured non-ASCII
locale will be closed as "won't fix".

Unsupporting platforms

If a platform drops out of tiered support, a note must be posted in this
PEP that the platform is no longer actively supported. This note must
include:

-   The name of the system,
-   The first release number that does not support this platform
    anymore, and
-   The first release where the historical support code is actively
    removed.

In some cases, it is not possible to identify the specific list of
systems for which some code is used (e.g. when autoconf tests for
absence of some feature which is considered present on all supported
systems). In this case, the name will give the precise condition
(usually a preprocessor symbol) that will become unsupported.

At the same time, the CPython build must be changed to produce a warning
if somebody tries to install CPython on this platform. On platforms
using autoconf, configure should also be made emit a warning about the
unsupported platform.

This gives potential users of the platform a chance to step forward and
offer maintenance. We do not treat a platform that loses Tier 3 support
any worse than a platform that was never supported.

No-longer-supported platforms

-   Name: MS-DOS, MS-Windows 3.x
    Unsupported in: Python 2.0
    Code removed in: Python 2.1

-   Name: SunOS 4
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: DYNIX
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: dgux
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: Minix
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: Irix 4 and --with-sgi-dl
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: Linux 1
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: Systems defining __d6_pthread_create (configure.in)
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: Systems defining PY_PTHREAD_D4, PY_PTHREAD_D6, or
    PY_PTHREAD_D7 in thread_pthread.h
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: Systems using --with-dl-dld
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: Systems using --without-universal-newlines,
    Unsupported in: Python 2.3
    Code removed in: Python 2.4

-   Name: MacOS 9
    Unsupported in: Python 2.4
    Code removed in: Python 2.4

-   Name: Systems using --with-wctype-functions
    Unsupported in: Python 2.6
    Code removed in: Python 2.6

-   Name: Win9x, WinME, NT4
    Unsupported in: Python 2.6 (warning in 2.5 installer)
    Code removed in: Python 2.6

-   Name: AtheOS
    Unsupported in: Python 2.6 (with "AtheOS" changed to "Syllable")
    Build broken in: Python 2.7 (edit configure to re-enable)
    Code removed in: Python 3.0
    Details: http://www.syllable.org/discussion.php?id=2320

-   Name: BeOS
    Unsupported in: Python 2.6 (warning in configure)
    Build broken in: Python 2.7 (edit configure to re-enable)
    Code removed in: Python 3.0

-   Name: Systems using Mach C Threads
    Unsupported in: Python 3.2
    Code removed in: Python 3.3

-   Name: SunOS lightweight processes (LWP)
    Unsupported in: Python 3.2
    Code removed in: Python 3.3

-   Name: Systems using --with-pth (GNU pth threads)
    Unsupported in: Python 3.2
    Code removed in: Python 3.3

-   Name: Systems using Irix threads
    Unsupported in: Python 3.2
    Code removed in: Python 3.3

-   Name: OSF* systems (issue 8606)
    Unsupported in: Python 3.2
    Code removed in: Python 3.3

-   Name: OS/2 (issue 16135)
    Unsupported in: Python 3.3
    Code removed in: Python 3.4

-   Name: VMS (issue 16136)
    Unsupported in: Python 3.3
    Code removed in: Python 3.4

-   Name: Windows 2000
    Unsupported in: Python 3.3
    Code removed in: Python 3.4

-   Name: Windows systems where COMSPEC points to command.com
    Unsupported in: Python 3.3
    Code removed in: Python 3.4

-   Name: RISC OS
    Unsupported in: Python 3.0 (some code actually removed)
    Code removed in: Python 3.4

-   Name: IRIX
    Unsupported in: Python 3.7
    Code removed in: Python 3.7

-   Name: Systems without multithreading support
    Unsupported in: Python 3.7
    Code removed in: Python 3.7

-   Name: wasm32-unknown-emscripten
    Unsupported in: Python 3.13
    Code removed in: Unknown

Discussions

-   April 2022: Consider adding a Tier 3 to tiered platform support
    (Victor Stinner)
-   March 2022: Proposed tiered platform support (Brett Cannon)
-   February 2015: Update to PEP 11 to clarify garnering platform
    support (Brett Cannon)
-   May 2014: Where is our official policy of what platforms we do
    support? (Brett Cannon)
-   August 2007: PEP 11 update - Call for port maintainers to step
    forward (Skip Montanaro)

Copyright

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