Supported platforms and architectures¶
See also Python on Android.
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
- ARMv7: should be well supported in practice
Well supported platforms¶
Well supported platforms on Python 3.7 and 2.7:
- 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
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 Supported Versions in Python (in the Python development
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
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).
- Python 3.7 dropped support for FreeBSD 9 and older.
- FreeBSD 9 buildbot wokers have been removed in 2017
Best effort and unofficial platforms¶
Supported platform with best effort support:
- Android API 24
- AIX 6.1 and newer
Platforms not supported officially:
- 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
- Solaris, OpenIndiana
PEP 11 lists removal of supported platforms:
- Platforms without threading support removed in Python 3.7
- BSD/OS, 2017:
- MS-DOS: 2014: bpo-22591: Drop support of MS-DOS (DJGPP compiler), commit b71c7dc9
- Python 3.4: VMS, OS/2, Windows 2000
- 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:
I want CPython to support my platform!¶
In short, there are 2 conditions:
- the full test suite have to pass (
./python -m testsucceess)
- 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.
Python has a good support for:
- Visual Studio MSC
- XLC on AIX 7
- 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
sys.platform versus os.name¶
sys.platform comes from the
MACHDEP variable which is built by the
configure script using:
uname -scommand output converted to lowercase, with some special rules (ex:
linux3is replaced with
linuxon Python 3)
uname -rcommand output (or
uname -vUnixWare or OpenUNIX)
./configure --host=xxxparameter) 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,
aix7 on all versions of Python through version Python 3.7.