This PEP documents how an operating system (platform) becomessupported in CPython, what platforms are currently supported, anddocuments past support.
Over time, the CPython source code has collected various pieces ofplatform-specific code, which, at some point in time, wasconsidered necessary to use CPython on a specific platform.Without access to this platform, it is not possible to determinewhether this code is still needed. As a result, this code mayeither break during CPython’s evolution, or it may becomeunnecessary as the platforms evolve as well.
Allowing these fragments to grow poses the risk ofunmaintainability: without having experts for a large number ofplatforms, it is not possible to determine whether a certainchange to the CPython source code will work on all supportedplatforms.
To reduce this risk, this PEP specifies what is required for aplatform to be considered supported by CPython as well as providing aprocedure to remove code for platforms with few or no CPythonusers.
This PEP also lists what platformsare supported by the CPythoninterpreter. This lets people know what platforms are directlysupported by the CPython development team.
Platform support is broken down intotiers. Each tier comes withdifferent requirements which lead to different promises being madeabout support.
To be promoted to a tier, steering council support is required and isexpected to be driven by team consensus. Demotion to a lower tieroccurs when the requirements of the current tier are no longer met fora platform for an extended period of time based on the judgment ofthe release manager or steering council. For platforms which no longermeet the requirements of any tier by b1 of a new feature release, anannouncement will be made to warn the community of the pending removalof support for the platform (e.g. in the b1 announcement). If theplatform is not brought into line for at least one of the tiers by thefirst release candidate, it will be listed as unsupported in this PEP.
main branch are not allowed to be merged;any breakage should be fixed or reverted immediately.main, and thus theseplatforms, working.| Target Triple | Notes |
|---|---|
| aarch64-apple-darwin | clang |
| aarch64-unknown-linux-gnu | glibc, gcc |
| i686-pc-windows-msvc | |
| x86_64-pc-windows-msvc | |
| x86_64-unknown-linux-gnu | glibc, gcc |
| Target Triple | Notes | Contacts |
|---|---|---|
| aarch64-unknown-linux-gnu | glibc, clang | Victor Stinner, Gregory P. Smith |
| wasm32-unknown-wasip1 | WASI SDK, Wasmtime | Brett Cannon, Michael Droettboom |
| x86_64-apple-darwin | macOS, clang | Sam Gross, Barry Warsaw, Ronald Oussoren |
| x86_64-unknown-linux-gnu | glibc, clang | Victor Stinner, Gregory P. Smith |
| Target Triple | Notes | Contacts |
|---|---|---|
| aarch64-linux-android | Russell Keith-Magee, Petr Viktorin | |
| aarch64-pc-windows-msvc | Steve Dower | |
| arm64-apple-ios | iOS on device | Russell Keith-Magee, Ned Deily |
| arm64-apple-ios-simulator | iOS on M1 macOS simulator | Russell Keith-Magee, Ned Deily |
| armv7l-unknown-linux-gnueabihf | 32-bit Raspberry Pi OS, gcc | Gregory P. Smith |
| aarch64-unknown-linux-gnu | 64-bit Raspberry Pi OS, gcc | Savannah Ostrowski |
| powerpc64le-unknown-linux-gnu | glibc, clang glibc, gcc | Victor Stinner Victor Stinner |
| s390x-unknown-linux-gnu | glibc, gcc | Victor Stinner |
| wasm32-unknown-emscripten | emcc | Russell Keith-Magee |
| x86_64-linux-android | Russell Keith-Magee, Petr Viktorin | |
| x86_64-unknown-freebsd | BSD libc, clang | Victor Stinner |
Support for a platform may be partial within the code base, such asfrom active development around platform support or accidentally.Code changes to platforms not listed in the above tiers may be rejectedor removed from the code base without a deprecation process if theycause a maintenance burden or obstruct general improvements.
Platforms not listed here may be supported by the wider Pythoncommunity in some way. If your desired platform is not listed above,please perform a search online to see if someone is already providingsupport in some form.
Windows versions prior to Windows 10 follow Microsoft’sFixed 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 customersas 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’sModern Lifecycle Policy,which varies per-product, per-version, per-edition and per-channel.Generally, feature updates (1709, 22H2) occur every 6-12 monthsand 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’sWindows Lifecycle FAQhas 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 versionswhoseextended support phase has not yet expired.Subsequent bug fix releases will support the same Windows versionsas the original feature release, even if no longer supported by Microsoft.New versions of Windows released while CPython is in maintenance modemay be supported at the discretion of the core team and release manager.
As of 2024, our current interpretation of Microsoft’s lifecycles is thatWindows 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 usuallybe the oldest version still receiving free security fixes, and that willdetermine 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 MicrosoftVisual Studio. That version should have mainstream support when therelease is made. Developers of extension modules will generally needto use the same Visual Studio release; they are concerned both withthe availability of the versions they need to use, and with keepingthe zoo of versions small. The CPython source tree will keepunmaintained build files for older Visual Studio releases, for whichpatches will be accepted. Such build files will be removed from thesource tree 3 years after the extended support for the compiler hasended (but continue to remain available in revision control).
Starting with CPython 3.7.0, *nix platforms are expected to provideat least one ofC.UTF-8 (full locale),C.utf8 (full locale) orUTF-8 (LC_CTYPE-only locale) as an alternative to the legacyClocale.
Any Unicode-related integration problems that occur only in the legacyClocale and cannot be reproduced in an appropriately configured non-ASCIIlocale will be closed as “won’t fix”.
If a platform drops out of tiered support, a note must be postedin this PEP that the platform is no longer actively supported. Thisnote must include:
In some cases, it is not possible to identify the specific list ofsystems for which some code is used (e.g. when autoconf tests forabsence of some feature which is considered present on allsupported systems). In this case, the name will give the precisecondition (usually a preprocessor symbol) that will becomeunsupported.
At the same time, the CPython build must be changed to produce awarning if somebody tries to install CPython on this platform. Onplatforms using autoconf, configure should also be made emit a warningabout the unsupported platform.
This gives potential users of the platform a chance to step forwardand offer maintenance. We do not treat a platform that loses Tier 3support any worse than a platform that was never supported.
This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.
Source:https://github.com/python/peps/blob/main/peps/pep-0011.rst
Last modified:2025-10-09 17:15:34 GMT