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 the CPython core team,as well as providing a procedure to remove code for platformswith few or no CPython users.
On the other hand, allowing these fragments in the main repositorycan promote collaboration, can help identify non-portable parts ofthe code base, and is necessary for bootstrapping support fora “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 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 |
All platforms not listed in the above tiers areunsupported by the core team.The core team does not develop and test on such platforms, and so theycannot provide any promises that Python will work on them.
However, the code base does include unsupported code – that is, codespecific to unsupported platforms.Contributions in this area are welcome as long as they:
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 unsupportedfixes to CPython’s maintenance branches.
Unsupported code thatdoes cause a maintenance burden, or obstructsgeneral improvements, may be rejected or removed from the code basewithout a deprecation process.Core team members that do this intentionally are encouraged to notify peoplelisted in thePlatforms experts list in the CPython contributor’s guide,to review any submitted fixes (if unobtrusive), and to consider addingconfiguration or extension capabilities necessary for workarounds.
People interested in unsupported platforms may add themselves to thePlatforms experts list to request that they be notified on issuesrelated to “their” platform.There is, however, no formal guarantee that theywill be notified.
Platforms not listed in this PEP may also be supported by the wider Pythoncommunity in other ways. 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).
Features specified in POSIX are expected to work according to the standard.This cuts two ways:
Workarounds for out-of-spec platforms are acceptable.For unsupported platforms, disabling functionality ispreferred over a non-trivial workaround.
For example, while POSIX specifieserrno as anint with norestrictions, error codes on all supported platforms happen to be positive.Relying on this would be considered a bug, even if it only manifests onunsupported platforms.
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:2026-01-23 17:28:10 GMT