Supported platforms and architectures

See also Python on Android.

Supported architectures

Well supported architectures:

• Intel x86 (32-bit) and x86_64 (64-bit, aka AMD64)

Best effort support architectures:

• ppc64le: should be well supported in practice

• AArch64

• ARMv7: should be well supported in practice

• s390x

Well supported platforms

Well supported platforms on Python 3.7 and 2.7:

• Linux

• Windows 8 and newer for Python 3.9

• FreeBSD 10 and newer

• macOS Snow Leopard (macOS 10.6, 2008) and newer

It took 9 years to fix all compiler warnings on Windows 64-bit! Usually, the fix was to use a larger type to avoid a downcast. For example replace int with Py_ssize_t.

Linux

CPython still has compatibility code for Linux 2.6, whereas the support of Linux 2.6.x ended in August 2011, longer than 6 years ago.

Proposition in January 2018 to drop support for old Linux kernels: https://mail.python.org/pipermail/python-dev/2018-January/151821.html

Windows

• Windows Supported Versions in Python (in the Python development master branch)

• Windows 7 support dropped in Python 3.9

• Windows Vista support dropped in Python 3.7

• Windows XP support dropped in Python 3.5

• Windows 2000 support dropped in Python 3.4

• bpo-23451, 2015-03: “Python 3.5 now requires Windows Vista or newer”. See change1 and change2.

• Python 3.7 supports Windows Vista and newer

• Python 2.7 supports Windows XP and newer

• PEP 11 on Windows:

  CPython’s Windows support now follows [Microsoft product support lifecycle]. A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired. Subsequent bug fix releases will support the same Windows releases as the original feature release (even if the extended support phase has ended).

FreeBSD

• Python 3.7 dropped support for FreeBSD 9 and older.

• FreeBSD 9 buildbot wokers have been removed in 2017

macOS

• 2018-05-28: macOS Snow Leopard (macOS 10.6, 2008) is currently the minimum officially supported macOS version.

• February 2018: Tiger (macOS 10.4, 2004) buildbots removed, which indirectly means that Tiger is no longer officially supported.

Tested by Travis CI and buildbots.

Best effort and unofficial platforms

Supported platform with best effort support:

• Android API 24

• OpenBSD

• NetBSD

• AIX 6.1 and newer

Platforms not supported officially:

• Cygwin

• HP-UX

  • HP-UX 11i v3 was first released in 2007. Latest HP-UX release: May 2020.

  • test_gdb fix in 2020: commit b2dca49ca3769cb60713f5c2b43e5d5bbdc1f9c7

  • os.chroot fix in 2020: commit a9edf44a2de9b23a1690b36cdfeed7b41ab763bd

• MinGW

• Solaris, OpenIndiana

Unofficial projects:

• Python for OpenVMS

• PythonD: PythonD is a 32-bit, multi-threaded, networking- and OpenGL-enabled Python interpreter for DOS and Windows.

Removed platforms

PEP 11 lists removal of supported platforms:

• Platforms without threading support removed in Python 3.7

  • https://bugs.python.org/issue31370

  • https://mail.python.org/pipermail/python-dev/2017-September/149156.html

  • https://github.com/python/cpython/commit/a6a4dc816d68df04a7d592e0b6af8c7ecc4d4344

• BSD/OS, 2017:

  • https://bugs.python.org/issue31624

  • https://github.com/python/cpython/commit/288d1daadaddf6ae35cf666138ba4b5d07449657

• MS-DOS: 2014: bpo-22591: Drop support of MS-DOS (DJGPP compiler), commit b71c7dc9

• Python 3.4: VMS, OS/2, Windows 2000

  • VMS: bpo-16136: Removal of VMS support, main removal commit (remove VMSError doc commit)

• IRIX (“The last major version of IRIX is IRIX 6.5, which was released in May 1998”)

  • Python 3.7: Remove dynload_dl (2020)

• AIX 5.3 and below

• Mac OS 9:

  • MacOS 9 dropped in Python 2.4 (see PEP 11)

  • bpo-35346: Drop Mac OS 9 support from platform

  • bpo-35471: Remove the macpath module (GH-11129)

I want CPython to support my platform!

In short, there are 2 conditions:

• the full test suite have to pass (./python -m test succeess)

• a CPython core developer has to be responsible of the platform to fix issues specific to this platform on CIs.

If it’s not possible, the best option is to maintain a fork of CPython (fork of the Git repository) to maintain patches to top of the master branch (and maybe also patches on other branches).

More detail in the PEP 11.

C compilers

Python has a good support for:

• GCC

• clang

• Visual Studio MSC

Best effort:

• XLC on AIX 7

Compiler flags:

• Debug build uses -Og

• Release build uses -O3

• clang with LTO

• clang with LTO+PGO

• GCC with LTO

• GCC with LTO+PGO

See Python Continuous Integration to see exactly which C compilers and which compiler and linker flags are actually tested.

See also Python builds.

See PEP 7 for the minimum C standard version. In short, it’s a subset of C99 with static line functions and <stdint.h>.

sys.platform versus os.name

Example of sys.platform and os.name values:

Platform	sys.platform	os.name
AIX	aix on Python3.8+, (**)	posix
FreeBSD	freebsd5, freebsd6, …	posix
Linux	linux on Python 3, linux2 on Python 2 (*)	posix
macOS	darwin	posix
NetBSD	netbsd (with a suffix?)	posix
OpenBSD	openbsd5	posix
Solaris	sunos5	posix
Windows	win32	nt

sys.platform comes from the MACHDEP variable which is built by the configure script using:

• uname -s command output converted to lowercase, with some special rules (ex: linux3 is replaced with linux on Python 3)

• uname -r command output (or uname -v UnixWare or OpenUNIX)

• $host variable (./configure --host=xxx parameter) when cross-compiling

(*) sys.platform was also linux3 on old versions of Python 2.6 and Python 2.7 with Linux kernel 3.x.

(**) On AIX sys.platform included a release digit, aix3, …, aix7 on all versions of Python through version Python 3.7.