PEP 11 – CPython-Plattformsunterstützung

Autor:: Martin von Löwis <martin at v.loewis.de>, Brett Cannon <brett at python.org>
Status:: Aktiv
Typ:: Prozess
Erstellt:: 07-Jul-2002
Post-History:: 18-Aug-2007, 14-May-2014, 20-Feb-2015, 10-Mar-2022

Inhaltsverzeichnis

Zusammenfassung
Begründung
Unterstützungsstufen
Nicht unterstützte Plattformen
Nicht mehr unterstützte Plattformen
Diskussionen
Urheberrecht

Zusammenfassung

Dieses PEP dokumentiert, wie ein Betriebssystem (Plattform) in CPython unterstützt wird, welche Plattformen derzeit unterstützt werden und dokumentiert die vergangene Unterstützung.

Im Laufe der Zeit hat sich im CPython-Quellcode verschiedener plattformspezifischer Code angesammelt, der zu einem bestimmten Zeitpunkt für die Verwendung von CPython auf einer bestimmten Plattform als notwendig erachtet wurde. Ohne Zugriff auf diese Plattform ist es nicht möglich festzustellen, ob dieser Code noch benötigt wird. Daher kann dieser Code entweder während der Entwicklung von CPython fehlschlagen oder unnötig werden, da sich auch die Plattformen weiterentwickeln.

Das Wachsen dieser Fragmente birgt das Risiko der mangelnden Wartbarkeit: Ohne Experten für eine große Anzahl von Plattformen ist es nicht möglich festzustellen, ob eine bestimmte Änderung am CPython-Quellcode auf allen unterstützten Plattformen funktioniert.

Um dieses Risiko zu reduzieren, legt dieses PEP fest, was für die Unterstützung einer Plattform durch CPython erforderlich ist, und bietet ein Verfahren zur Entfernung von Code für Plattformen mit wenigen oder keinen CPython-Benutzern.

Dieses PEP listet auch auf, welche Plattformen vom CPython-Interpreter unterstützt werden. Dies informiert die Leute darüber, welche Plattformen vom CPython-Entwicklungsteam direkt unterstützt werden.

Unterstützungsstufen

Die Plattformsunterstützung ist in Stufen unterteilt. Jede Stufe hat unterschiedliche Anforderungen, die zu unterschiedlichen Zusagen bezüglich der Unterstützung führen.

Um in eine Stufe aufzusteigen, ist die Unterstützung des Steering Council erforderlich und wird voraussichtlich durch Konsens des Teams getragen. Ein Herabstufen auf eine niedrigere Stufe erfolgt, wenn die Anforderungen der aktuellen Stufe über einen längeren Zeitraum nicht mehr erfüllt werden, nach Ermessen des Release Managers oder des Steering Council. Für Plattformen, die bis b1 einer neuen Feature-Version die Anforderungen keiner Stufe mehr erfüllen, wird eine Ankündigung gemacht, um die Community vor der drohenden Entfernung der Unterstützung für die Plattform zu warnen (z. B. in der b1-Ankündigung). Wenn die Plattform bis zur ersten Release Candidate nicht mindestens eine der Stufen erfüllt, wird sie in diesem PEP als nicht unterstützt aufgeführt.

Stufe 1

STATUS
CI-Fehler blockieren Releases.
Änderungen, die den main-Branch beschädigen würden, dürfen nicht gemergt werden; jegliche Beschädigung sollte sofort behoben oder rückgängig gemacht werden.
Alle Core Developer sind dafür verantwortlich, dass main und damit diese Plattformen funktionieren.
Fehler auf diesen Plattformen blockieren ein Release.

Target Triple	Anmerkungen
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

Stufe 2

STATUS
Muss einen zuverlässigen Buildbot haben.
Mindestens zwei Core Developer haben sich zur Unterstützung der Plattform gemeldet.
Änderungen, die eine dieser Plattformen beschädigen, müssen innerhalb von 24 Stunden behoben oder rückgängig gemacht werden.
Fehler auf diesen Plattformen blockieren ein Release.

Target Triple	Anmerkungen	Kontakte
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

Stufe 3

STATUS
Muss einen zuverlässigen Buildbot haben.
Mindestens ein Core Developer hat sich zur Unterstützung der Plattform gemeldet.
Keine SLA-Reaktionszeit bei Fehlern.
Fehler auf diesen Plattformen blockieren kein Release.

Target Triple	Anmerkungen	Kontakte
aarch64-linux-android		Russell Keith-Magee, Petr Viktorin
aarch64-pc-windows-msvc		Steve Dower
arm64-apple-ios	iOS auf Gerät	Russell Keith-Magee, Ned Deily
arm64-apple-ios-simulator	iOS auf 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

Alle anderen Plattformen

Die Unterstützung einer Plattform kann im Codebase teilweise vorhanden sein, z. B. durch aktive Entwicklung rund um die Plattformsunterstützung oder versehentlich. Codeänderungen für Plattformen, die nicht in den oben genannten Stufen aufgeführt sind, können ohne ein Deprecation-Verfahren abgelehnt oder aus dem Codebase entfernt werden, wenn sie eine Wartungsbelastung verursachen oder allgemeine Verbesserungen behindern.

Plattformen, die hier nicht aufgeführt sind, können von der breiteren Python-Community in irgendeiner Form unterstützt werden. Wenn Ihre gewünschte Plattform oben nicht aufgeführt ist, führen Sie bitte eine Online-Suche durch, um festzustellen, ob bereits jemand eine Form der Unterstützung anbietet.

Anmerkungen

Microsoft Windows

Windows-Versionen vor Windows 10 folgen der Fixed Lifecycle Policy von Microsoft, mit einer Mainstream-Supportphase von 5 Jahren nach der Veröffentlichung, in der das Produkt allgemein kommerziell verfügbar ist, und einer zusätzlichen 5-jährigen erweiterten Supportphase, in der bezahlter Support noch verfügbar ist und bestimmte Fehlerkorrekturen veröffentlicht werden. Extended Security Updates (ESU) ist ein kostenpflichtiges Programm, das für Großkunden als "letzter Ausweg" verfügbar ist, um bestimmte Sicherheitsupdates nach Ablauf des erweiterten Supports zu erhalten. ESU gilt als eigenständige Phase, die auf den Ablauf des erweiterten Supports folgt.

Windows 10 und neuere Versionen folgen der Modern Lifecycle Policy von Microsoft, die je nach Produkt, Version, Edition und Kanal variiert. Im Allgemeinen erfolgen Funktionsupdates (1709, 22H2) alle 6-12 Monate und werden 18-36 Monate lang unterstützt; Server- und IoT-Editionen sowie LTSC-Kanal-Releases werden 5-10 Jahre lang unterstützt, und die neueste Feature-Version einer Hauptversion (Windows 10, Windows 11) erhält in der Regel mindestens 10 Jahre nach der Veröffentlichung neue Updates. Die Windows Lifecycle FAQ von Microsoft enthält spezifischere und aktuellere Informationen.

CPython's Windows-Unterstützung folgt derzeit den Lebenszyklen von Microsoft. Eine neue Feature-Version X.Y.0 unterstützt alle Windows-Versionen, deren erweiterte Supportphase noch nicht abgelaufen ist. Nachfolgende Fehlerkorrektur-Releases unterstützen die gleichen Windows-Versionen wie die ursprüngliche Feature-Version, auch wenn diese von Microsoft nicht mehr unterstützt werden. Neue Windows-Versionen, die veröffentlicht werden, während sich CPython im Wartungsmodus befindet, können nach Ermessen des Core-Teams und des Release Managers unterstützt werden.

Stand 2024 ist unsere aktuelle Interpretation der Microsoft-Lebenszyklen, dass Windows für IoT und eingebettete Systeme nicht mehr im Geltungsbereich neuer CPython-Releases liegt, da die Absicht hierbei darin besteht, Funktionsupdates zu vermeiden. Windows Server wird normalerweise die älteste Version sein, die weiterhin kostenlose Sicherheitsupdates erhält, und dies bestimmt die früheste unterstützte Client-Version mit äquivalenter API-Version (die normalerweise über ihr End-of-Life hinausgeht).

Jede Feature-Version wird von einer bestimmten Version von Microsoft Visual Studio erstellt. Diese Version sollte während der Veröffentlichung der Version den Mainstream-Support haben. Entwickler von Erweiterungsmodulen müssen im Allgemeinen die gleiche Visual Studio-Version verwenden; sie sind sowohl an der Verfügbarkeit der von ihnen benötigten Versionen als auch an der Verkleinerung des Versions-Zoos interessiert. Der CPython-Quellbaum wird unbetreute Build-Dateien für ältere Visual Studio-Versionen beibehalten, für die Patches akzeptiert werden. Solche Build-Dateien werden 3 Jahre nach Ende des erweiterten Supports für den Compiler aus dem Quellbaum entfernt (bleiben aber in der Versionskontrolle verfügbar).

Legacy C-Locale

Ab CPython 3.7.0 wird von *nix-Plattformen erwartet, dass sie mindestens eine der folgenden Optionen anbieten: C.UTF-8 (vollständige Locale), C.utf8 (vollständige Locale) oder UTF-8 (nur LC_CTYPE-Locale) als Alternative zur Legacy- C-Locale.

Alle Unicode-bezogenen Integrationsprobleme, die nur in der Legacy- C-Locale auftreten und nicht in einer entsprechend konfigurierten Nicht-ASCII-Locale reproduziert werden können, werden als "won't fix" (wird nicht behoben) geschlossen.

Nicht unterstützte Plattformen

Wenn eine Plattform aus der gestaffelten Unterstützung herausfällt, muss eine Notiz in diesem PEP veröffentlicht werden, dass die Plattform nicht mehr aktiv unterstützt wird. Diese Notiz muss enthalten:

Den Namen des Systems,
Die erste Release-Nummer, die diese Plattform nicht mehr unterstützt, und
Die erste Release, bei der der historische Support-Code aktiv entfernt wird.

In einigen Fällen ist es nicht möglich, die spezifische Liste der Systeme zu identifizieren, für die ein Code verwendet wird (z. B. wenn Autoconf auf die Abwesenheit eines bestimmten Merkmals testet, das auf allen unterstützten Systemen vorhanden ist). In diesem Fall gibt der Name die genaue Bedingung (normalerweise ein Präprozessor-Symbol) an, die dann nicht mehr unterstützt wird.

Gleichzeitig muss der CPython-Build geändert werden, um eine Warnung auszugeben, wenn jemand versucht, CPython auf dieser Plattform zu installieren. Auf Plattformen, die Autoconf verwenden, sollte Configure ebenfalls eine Warnung über die nicht unterstützte Plattform ausgeben.

Dies gibt potenziellen Benutzern der Plattform die Möglichkeit, sich zu melden und die Wartung anzubieten. Eine Plattform, die den Tier-3-Support verliert, wird nicht schlechter behandelt als eine Plattform, die nie unterstützt wurde.

Nicht mehr unterstützte Plattformen

Name: MS-DOS, MS-Windows 3.x

Nicht unterstützt in: Python 2.0

Code entfernt in: Python 2.1
Name: SunOS 4

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: DYNIX

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: dgux

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: Minix

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: Irix 4 und –with-sgi-dl

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: Linux 1

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: Systeme, die __d6_pthread_create definieren (configure.in)

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: Systeme, die PY_PTHREAD_D4, PY_PTHREAD_D6 oder PY_PTHREAD_D7 in thread_pthread.h definieren

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: Systeme, die –with-dl-dld verwenden

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: Systeme, die –without-universal-newlines verwenden,

Nicht unterstützt in: Python 2.3

Code entfernt in: Python 2.4
Name: MacOS 9

Nicht unterstützt in: Python 2.4

Code entfernt in: Python 2.4
Name: Systeme, die –with-wctype-functions verwenden

Nicht unterstützt in: Python 2.6

Code entfernt in: Python 2.6
Name: Win9x, WinME, NT4

Nicht unterstützt in: Python 2.6 (Warnung im 2.5 Installer)

Code entfernt in: Python 2.6
Name: AtheOS

Nicht unterstützt in: Python 2.6 (mit "AtheOS" zu "Syllable" geändert)

Build kaputt in: Python 2.7 (configure bearbeiten, um es wieder zu aktivieren)

Code entfernt in: Python 3.0

Details: http://www.syllable.org/discussion.php?id=2320
Name: BeOS

Nicht unterstützt in: Python 2.6 (Warnung in configure)

Build kaputt in: Python 2.7 (configure bearbeiten, um es wieder zu aktivieren)

Code entfernt in: Python 3.0
Name: Systeme, die Mach C Threads verwenden

Nicht unterstützt in: Python 3.2

Code entfernt in: Python 3.3
Name: SunOS Lightweight Processes (LWP)

Nicht unterstützt in: Python 3.2

Code entfernt in: Python 3.3
Name: Systeme, die –with-pth (GNU pth threads) verwenden

Nicht unterstützt in: Python 3.2

Code entfernt in: Python 3.3
Name: Systeme, die Irix Threads verwenden

Nicht unterstützt in: Python 3.2

Code entfernt in: Python 3.3
Name: OSF* Systeme (Issue 8606)

Nicht unterstützt in: Python 3.2

Code entfernt in: Python 3.3
Name: OS/2 (Issue 16135)

Nicht unterstützt in: Python 3.3

Code entfernt in: Python 3.4
Name: VMS (Issue 16136)

Nicht unterstützt in: Python 3.3

Code entfernt in: Python 3.4
Name: Windows 2000

Nicht unterstützt in: Python 3.3

Code entfernt in: Python 3.4
Name: Windows-Systeme, bei denen COMSPEC auf command.com zeigt

Nicht unterstützt in: Python 3.3

Code entfernt in: Python 3.4
Name: RISC OS

Nicht unterstützt in: Python 3.0 (ein Teil des Codes wurde tatsächlich entfernt)

Code entfernt in: Python 3.4
Name: IRIX

Nicht unterstützt in: Python 3.7

Code entfernt in: Python 3.7
Name: Systeme ohne Multithreading-Unterstützung

Nicht unterstützt in: Python 3.7

Code entfernt in: Python 3.7

Diskussionen

April 2022: Consider adding a Tier 3 to tiered platform support (Victor Stinner)
März 2022: Proposed tiered platform support (Brett Cannon)
Februar 2015: Update to PEP 11 to clarify garnering platform support (Brett Cannon)
Mai 2014: Where is our official policy of what platforms we do support? (Brett Cannon)
August 2007: PEP 11 update - Call for port maintainers to step forward (Skip Montanaro)

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.

Quelle: https://github.com/python/peps/blob/main/peps/pep-0011.rst

Zuletzt geändert: 2025-10-09 17:15:34 GMT