PEP: 11
Title: CPython platform support
Author: Martin von Löwis <martin@v.loewis.de>,
        Brett Cannon <brett@python.org>
Status: Active
Type: Process
Created: 07-Jul-2002
Post-History: `18-Aug-2007 <https://mail.python.org/archives/list/python-dev@python.org/thread/DSSGXU5LBCMKYMZBRVB6RF3YAB6ST5AV/>`__,
              `14-May-2014 <https://mail.python.org/archives/list/python-dev@python.org/thread/T7WTUJ6TD3IGYGWV3M4PHJWNLM2WPZAW/>`__,
              `20-Feb-2015 <https://mail.python.org/archives/list/python-dev@python.org/thread/OEQHRR2COYZDL6LZ42RBZOMIUB32WI34/>`__,
              `10-Mar-2022 <https://mail.python.org/archives/list/python-committers@python.org/thread/K757345KX6W5ZLTWYBUXOXQTJJTL7GW5/>`__,
              `21-Nov-2025 <https://discuss.python.org/t/104986>`__,


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 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.


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 <https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__
- 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
aarch64-unknown-linux-gnu glibc, gcc
i686-pc-windows-msvc
x86_64-pc-windows-msvc
x86_64-unknown-linux-gnu  glibc, gcc
========================= =====


Tier 2
------

- `STATUS <https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-2>`__
- 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
============================= ========================== ========
aarch64-unknown-linux-gnu     glibc, clang               Victor Stinner, Gregory P. Smith
aarch64-pc-windows-msvc                                  Steve Dower, Diego Russo, Chris Eibl
wasm32-unknown-wasip1         WASI SDK, Wasmtime         Brett Cannon, Michael Droettboom, Savannah Ostrowski
x86_64-apple-darwin           macOS, clang               Sam Gross, Barry Warsaw, Ronald Oussoren
x86_64-unknown-linux-gnu      glibc, clang               Victor Stinner, Gregory P. Smith
============================= ========================== ========


Tier 3
------

- `STATUS <https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-3>`__
- 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
================================ =========================== ========
aarch64-linux-android                                        Russell Keith-Magee, Petr Viktorin
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, Stan Ulbrych
powerpc64le-unknown-linux-gnu    glibc, clang                Victor Stinner

                                 glibc, gcc                  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
================================ =========================== ========


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 `Ports and contacts list`_ in the Python developer'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
`Ports and contacts list`_ to request that they be notified on issues
related to "their" platform.
There is, however, no formal guarantee that they *will* be notified.

.. _Ports and contacts list: https://devguide.python.org/developer-workflow/porting/#ports-and-contacts

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.


Notes
-----

Microsoft Windows
'''''''''''''''''

Windows versions prior to Windows 10 follow Microsoft's `Fixed Lifecycle Policy
<https://learn.microsoft.com/en-us/lifecycle/policies/fixed>`__,
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)
<https://learn.microsoft.com/en-us/lifecycle/faq/extended-security-updates>`_
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
<https://learn.microsoft.com/en-us/lifecycle/policies/modern>`__,
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
<https://learn.microsoft.com/en-us/lifecycle/faq/windows>`_
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).


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
'''''''''''''''

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".


.. _wasi-support:

WASI
''''

WASI support is defined in :pep:`816`.

====== ==== ========
Python WASI WASI SDK
====== ==== ========
3.15   0.1  33
3.14   0.1  24
3.13   0.1  24
3.12   0.1  21
3.11   0.1  21
====== ==== ========

All versions prior to Python 3.15 predate :pep:`816`. The version support for
those earlier versions is based on what was supported when that PEP was
written.

WASI was a tier 3 platform for Python 3.11 and 3.12, and became a tier 2
platform starting with Python 3.13.

WASI 0.2 support has been skipped due to lack of time, to the point that it was
deemed better to go straight to WASI 0.3 instead. This is based on a
recommendation from the `Bytecode Alliance <https://bytecodealliance.org>`__.

WASI SDK 26 and 27 have a
`bug <https://github.com/WebAssembly/wasi-libc/issues/617>`__ which causes
CPython to hang in certain situations, and so they have been skipped.


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


Discussions
===========

* November 2025: `Policy for unsupported platforms
  <https://discuss.python.org/t/104986>`_
  (Petr Viktorin)
* April 2022: `Consider adding a Tier 3 to tiered platform support
  <https://mail.python.org/archives/list/python-committers@python.org/thread/V3OZPJGA5VJFYM6XYGPZIVPOIYKX6KTD/>`_
  (Victor Stinner)
* March 2022: `Proposed tiered platform support
  <https://mail.python.org/archives/list/python-committers@python.org/thread/K757345KX6W5ZLTWYBUXOXQTJJTL7GW5/>`_
  (Brett Cannon)
* February 2015: `Update to PEP 11 to clarify garnering platform support
  <https://mail.python.org/archives/list/python-dev@python.org/thread/OEQHRR2COYZDL6LZ42RBZOMIUB32WI34/>`_
  (Brett Cannon)
* May 2014: `Where is our official policy of what platforms we do support?
  <https://mail.python.org/archives/list/python-dev@python.org/thread/T7WTUJ6TD3IGYGWV3M4PHJWNLM2WPZAW/>`_
  (Brett Cannon)
* August 2007: `PEP 11 update - Call for port maintainers to step forward
  <https://mail.python.org/archives/list/python-dev@python.org/thread/DSSGXU5LBCMKYMZBRVB6RF3YAB6ST5AV/>`_
  (Skip Montanaro)


Copyright
=========

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