Vorgeschlagener Eintrag „Was ist neu in Python 3.9“

Die folgende Unterabschnitt würde dem Dokument „Was ist neu in Python 3.9“ hinzugefügt und von jeder Python 3.9 Alpha- und Beta-Ankündigung verlinkt werden.

Python-Requires: >= "3.9.0b6"; python_version == "3.9" and full_python_version != "3.9.0a5"

Beispielhafter Ankündigungstext für das Release 3.9.0a1

Dies ist die erste Vorschauversion von Python 3.9. Als Alpha-Release ist sie für Kompatibilitätstests von Bibliotheken und Anwendungen sowie für die Erstellung von ABI-kompatiblen Binärartefakten bestimmt. Die Verwendung in Produktionsumgebungen wird nicht empfohlen.

Beispielhafter Ankündigungstext für das Release 3.9.0b2

Dies ist die zweite Vorschauversion von Python 3.9. Als Beta-Release ist sie vollständig binärkompatibel mit dem vorherigen 3.9.0a1-Release. Die Verwendung in Produktionsumgebungen wird nur in Umgebungen mit ausreichend robusten Integrations-Tests und operativen Überwachungsfunktionen empfohlen.

(Rest wie in der Ankündigung von 3.9.0a1, mit Aktualisierungen für implementierte Änderungen und dem nächsten erwarteten Release 3.9.0b3)

Beispielhafter Ankündigungstext für 3.9.0a5 (eine Alpha-Version mitten im Stream)

Dies ist die fünfte Vorschauversion von Python 3.9. Als Alpha-Release ist sie NICHT vollständig binärkompatibel mit dem vorherigen 3.9.0b4-Release. Dieses Release ist für Kompatibilitätstests von Bibliotheken und Anwendungen sowie für die Erstellung von ABI-kompatiblen Binärartefakten bestimmt. Die Verwendung in Produktionsumgebungen wird nicht empfohlen.

Python-Requires: >= "3.9.0b6"; python_version == "3.9" and full_python_version != "3.9.0a5"

Beispielhafter Ankündigungstext für 3.9.0rc1

Dies ist der erste Release Candidate für Python 3.9. Als Release Candidate ist dieses Release nun funktionsvollständig, die vollständige CPython-ABI ist nun eingefroren, und das Pre-Release-Marker wurde von den ABI-Kompatibilitätsflags entfernt. Die Verwendung in Produktionsumgebungen wird nur in Umgebungen mit ausreichend robusten Integrations-Tests und operativen Überwachungsfunktionen empfohlen.

Zwei-Jahres-Kadenz für stabile Releases

Da die rollierenden Pre-Freeze-Releases für Benutzer verfügbar sind, die die neuesten Versionen des Referenzinterpreters und der Standardbibliothek nutzen möchten, schlägt dieser PEP vor, die Häufigkeit von X.Y.0-Releases anzupassen, um alle zwei Jahre im August eine neue stabile Version zu veröffentlichen (beginnend 2021, etwa zwei Jahre nach der Veröffentlichung von Python 3.8.0).

Diese Änderung ist wohl orthogonal zu den vorgeschlagenen Änderungen an der Handhabung der Pre-Freeze-Release-Periode, aber die Verbindung ist, dass ohne diese Änderungen am Pre-Release-Management die Nachteile einer Zwei-Jahres-Full-Release-Kadenz die Vorteile wahrscheinlich überwiegen würden, während das Gegenteil für eine 12-Monats-Release-Kadenz gilt (d. h. mit den in diesem PEP vorgeschlagenen Änderungen am Pre-Release-Management würden die Nachteile einer 12-Monats-Full-Release-Kadenz die Vorteile überwiegen).

Zusammenlegung der Alpha- und Beta-Phasen zu einer „Pre-Freeze“-Phase

Anstatt des Status quo fortzuführen, bei dem die Alpha- und Beta-Phasen vor der Veröffentlichung getrennt und sequenziell sind, schlägt dieser PEP vor, sie stattdessen in eine einzige „Pre-Freeze“-Phase mit einer monoton steigenden Seriennummer für die Releases zu kombinieren.

Anstatt getrennte Phasen zu bezeichnen, würden die Namen „Alpha“ und „Beta“ stattdessen angeben, ob das Release abwärts inkompatible Änderungen an der vollständigen CPython-C-ABI enthält oder nicht.

• „Alpha“-Releases wären „ABI-breaking“-Releases, bei denen Erweiterungsmodule, die gegen die vollständige CPython-ABI im vorhergehenden Pre-Release kompiliert wurden, nicht unbedingt korrekt geladen werden.
• „Beta“-Releases wären „binärkompatible“ Releases, bei denen Erweiterungsmodule, die gegen die vollständige CPython-ABI im vorhergehenden Pre-Release kompiliert wurden, voraussichtlich korrekt geladen werden, solange diese Module die folgenden zusätzlichen Kriterien einhalten:
  • das Modul darf keine provisorischen oder privaten C-APIs (entweder aus der vorherigen stabilen Release-Serie oder der in Entwicklung befindlichen Pre-Release-Serie) verwenden, die in diesem Beta-Release entfernt oder auf eine ABI-inkompatible Weise geändert wurden.
  • das Modul darf keine C-APIs verwenden, die in der vorherigen stabilen Release-Serie als veraltet markiert und in diesem Beta-Release entfernt wurden.

Release-Candidate-Politik, Phasen-Dauer und Kadenz

Angesichts der vorgeschlagenen Änderungen an den Alpha- und Beta-Release-Phasen würde die Release-Candidate-Phase die folgenden damit verbundenen Anpassungen erfahren:

• Feature-Freeze, ABI-Freeze, pyc-Dateiformat-Freeze und die Erstellung des Wartungszweigs würden alle mit der Erstellung von X.Y.0rc1 zusammenfallen (derzeit geschehen diese über eine Mischung aus X.Y.0b1, der letzten Beta-Version und X.Y.0rc1).
• Die X.Y.0 Release-Candidate-Periode würde von 3 Wochen auf 2 Monate verlängert.
• Normalerweise würden zwei Release Candidates im Abstand von einem Monat herausgegeben, aber zusätzliche Candidates können nach Ermessen des Release Managers veröffentlicht werden.
• Die endgültige X.Y.0-Version würde zwischen 1 und 4 Wochen nach dem letzten Release Candidate erfolgen (abhängig davon, ob nach dem zweiten zusätzliche Release Candidates benötigt wurden).
• Wenn die endgültige X.Y.0-Version über das August-Zieldatum hinaus verzögert wird, wird die nachfolgende Release-Serie nicht beeinträchtigt und wird weiterhin für August geplant (jetzt knapp zwei Jahre später).

Zusätzlich zur größeren Zeit für Endbenutzerfeedback zu den Release Candidates bietet diese angepasste Richtlinie den Maintainern von Python-Projekten zusätzliche Zeit, um vorab kompilierte Wheel-Archive für die neue stabile Release-Serie zu erstellen und zu veröffentlichen, was die anfängliche Benutzererfahrung der X.Y.0-Version erheblich verbessert.

Änderungen an der Verwaltung der stabilen CPython-C-ABI

Die stabile CPython-ABI [5] verpflichtet sich, dass Binär-Erweiterungsmodule, die gegen eine bestimmte CPython-Version kompiliert wurden, auch mit zukünftigen CPython-Versionen funktionieren, die dieselbe stabile ABI-Version unterstützen (diese Version ist derzeit abi3).

Unter dem vorgeschlagenen Rolling-Pre-Freeze-Release-Modell würde diese Verpflichtung erweitert, um auch für Beta-Versionen zu gelten: Sobald eine beabsichtigte Ergänzung zur stabilen ABI abi3 für die kommende Python-Version in einer Beta-Version ausgeliefert wurde, wird sie für zukünftige Versionen nicht mehr entfernt, solange die stabile ABI-Version abi3 unterstützt wird.

Zwei Hauptmechanismen stehen zur Verfügung, um Community-Feedback zu Ergänzungen zur stabilen ABI zu erhalten:

• Der bevorzugte Mechanismus ist, neue APIs zuerst zur vollständigen CPython-API hinzuzufügen und sie erst zur stabilen ABI zu befördern, nachdem sie in mindestens einer veröffentlichten Beta-Version enthalten waren und relevantes Benutzerfeedback erhalten haben.
• Für APIs, bei denen dieser Ansatz aus irgendeinem Grund nicht verfügbar ist (z. B. einige API-Ergänzungen dienen keinem nützlichen Zweck, wenn die vollständige CPython-API verfügbar ist), können Entwickler den Release-Manager bitten, die nächste Version als Alpha-Version zu kennzeichnen (auch ohne ABI-Bruch in der vollständigen CPython-API) und auf diese Weise weiteres Feedback zu erhalten.

Als leichte Verbesserung der Lesbarkeit und Benutzerfreundlichkeit schlägt diese PEP auch die Einführung von Aliassen für jede wichtige stabile ABI-Version vor.

#define Py_LIMITED_API_3_3 0x03030000
#define Py_LIMITED_API_3_4 0x03040000
#define Py_LIMITED_API_3_5 0x03050000
#define Py_LIMITED_API_3_6 0x03060000
#define Py_LIMITED_API_3_7 0x03070000
#define Py_LIMITED_API_3_8 0x03080000
#define Py_LIMITED_API_3_9 0x03090000
// etc...

Diese würden sowohl im Code von Erweiterungsmodulen verwendet, um die Ziel-ABI-Version festzulegen,

#define Py_LIMITED_API Py_LIMITED_API_3_8

Als auch in der CPython-Interpreter-Implementierung, um zu überprüfen, welche Symbole verfügbar gemacht werden sollen.

#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= Py_LIMITED_API_3_9
// A Python 3.9+ addition to the stable ABI would appear here
#endif

Die Dokumentation für die Rolling-Pre-Freeze-Releases und die stabile C-ABI würde klarstellen, dass Erweiterungsmodule, die gegen die stabile ABI in einer späteren Pre-Freeze-Veröffentlichung kompiliert wurden, möglicherweise nicht korrekt auf einer früheren Pre-Freeze-Veröffentlichung geladen werden.

Die Dokumentation für Alpha-Versionen und die stabile C-ABI würde klarstellen, dass selbst Erweiterungsmodule, die gegen die stabile ABI in einer Alpha-Version kompiliert wurden, möglicherweise nicht korrekt auf der nächsten Version geladen werden, wenn zwei Alpha-Versionen nacheinander veröffentlicht werden (dieser Fall wäre idealerweise selten).

Änderungen an der Verwaltung der vollständigen CPython-ABI

Diese PEP schlägt zwei Änderungen an der Verwaltung der vollständigen CPython-ABI vor.

Aktualisierung von „Python-Requires“ für Projekte, die von Änderungen an der vollständigen C-ABI betroffen sind

Wenn ein Projekt zum ersten Mal beschließt, vorab kompilierte binäre Wheels für die Rolling-Pre-Freeze-Release-Serie bereitzustellen, müssen sie nichts Besonderes tun: Sie würden die Rolling-Release-Serie zu ihren Build- und Testmatrizen hinzufügen und binäre Archive veröffentlichen, die als kompatibel mit dieser Release-Serie gekennzeichnet sind, genau wie sie es tun würden, wenn sie vorab kompilierte binäre Wheels nach dem vollständigen CPython-ABI-Freeze für diese Release-Serie bereitstellen würden.

Wenn das Projekt jedoch von einem CPython-ABI-Kompatibilitätsbruch im Rolling-Release-Stream betroffen ist, müssen sie eine Versionsaktualisierung herausgeben, die sowohl den neuen Binär-Build als auch einen neuen, umgebungseingeschränkten Python-Requires-Marker enthält.

Wenn beispielsweise ein Projekt, das den Rolling-Release-Stream unterstützt, von einem CPython-ABI-Kompatibilitätsbruch in der 3.9.0a5-Version betroffen war, würden sie den folgenden Metadateneintrag auf die Version setzen, die den aktualisierten Binär-Build veröffentlicht hat:

Python-Requires: >= "3.9.0b6"; python_version == "3.9" and full_python_version != "3.9.0a5"

Dies fügt eine zusätzliche Kompatibilitätsbeschränkung als Teil der veröffentlichten Pakete hinzu, sodass Python 3.9.0 Beta-Versionen vor 3.9.0b6 das aktualisierte Paket nicht als Installationskandidaten betrachten, und die einzige Alpha-Version, die das Paket berücksichtigen wird, ist 3.9.0a5 selbst.

Warum rollierende Pre-Freeze-Releases anstelle von einfach häufigeren X.Y.0-Releases?

Für große Teile der Python-Benutzerbasis ist die Verfügbarkeit neuer CPython-Feature-Releases nicht der limitierende Faktor für ihre Übernahme dieser neuen Releases (dieser Effekt zeigt sich in Metriken wie PyPI-Download-Metadaten).

Daher muss jeder Vorschlag, der auf der Beschleunigung vollständiger Feature-Releases basiert, ein Gleichgewicht finden zwischen der Erfüllung der Bedürfnisse von Benutzern, die jede Version übernehmen würden, sobald sie verfügbar ist, und denen, die nun in der Lage wären, jede 2., 3. oder 4. Version zu übernehmen, anstatt fast jede Version im Laufe ihres Lebenszyklus migrieren zu können.

Dieser Vorschlag zielt darauf ab, das Problem aus einem anderen Blickwinkel anzugehen, indem ein neuer produktionsreifer Release-Stream definiert wird, der speziell auf die Interessen von Betriebsumgebungen zugeschnitten ist, die neue Releases so schnell konsumieren können, wie das CPython-Core-Team sie produzieren kann.

Ist es notwendig, das Namensschema „Alpha“ und „Beta“ beizubehalten?

Die Verwendung der „a“- und „b“-Kürzel für die vorgeschlagenen Rolling-Releases ist eine Designbeschränkung, die sich aus einigen pragmatischen Aspekten der Veröffentlichung von CPython-Versionsnummern ergibt.

Insbesondere Alpha-Versionen, Beta-Versionen und Release Candidates werden an einigen Stellen mit den Zeichenketten „a“, „b“ und „c“ gemeldet, während sie an anderen Stellen mit den Hexadezimalziffern 0xA, 0xB und 0xC gemeldet werden. Wir möchten dies beibehalten und gleichzeitig sicherstellen, dass alle Python-Requires-Beschränkungen gegen die Beta-Versionen und nicht gegen die Alpha-Versionen ausgedrückt werden (da letztere möglicherweise keine abi3-Stabilitätsanforderungen erzwingen, wenn zwei Alpha-Versionen nacheinander auftreten).

Es gibt jedoch nichts, was uns zwingt zu sagen, dass „a“ für „Alpha“ oder „b“ für „Beta“ steht.

Das bedeutet, dass, wenn wir die Akzeptanz bei Leuten erhöhen wollen, die nur durch das Label „Beta“ abgeschreckt wurden, es sinnvoll sein könnte, die Namen „*A*BI breaking“ und „*B*inary compatible“ gegenüber den Namen „Alpha“ und „Beta“ zu betonen, was zu Folgendem führt:

• 3.9.0a1: ABI-breaking Pre-Freeze-Version
• 3.9.0b2: Binärkompatible Pre-Freeze-Version
• 3.9.0rc1: Release Candidate
• 3.9.0: Finale Version

Diese Iteration der PEP geht nicht so weit, da die Begrenzung der anfänglichen Akzeptanz der Rolling-Pre-Freeze-Versionen auf Personen, die mit dem Label „Beta“ vertraut sind, wahrscheinlich gut ist, da es die Early Adopters dieser Versionen sind, die auf unerwartete Konsequenzen auf der Ebene des breiteren Python-Ökosystems stoßen werden, und wir brauchen sie, um aktiv an der Lösung dieser Probleme teilzunehmen.

Eine Abkehr von der Beta-Namensgebung wäre dann eine Option, die für die Zukunft im Auge zu behalten wäre, vorausgesetzt, die daraus resultierende Erfahrung ist ausreichend positiv, dass wir entscheiden, dass der Ansatz fortgesetzt werden soll.

Warum rollierende Pre-Freeze-Releases anstelle von abwechselnden stabilen und instabilen Release-Serien?

Anstatt die Beta-Phase für Rolling-Releases zu nutzen, wäre eine andere Option, zwischen traditionellen stabilen Releases (für 3.8.x, 3.10.x usw.) und Release-Serien, die die neue Rolling-Release-Kadenz nutzten (für 3.9.x, 3.11.x usw.), abzuwechseln.

Diese Idee leidet unter demselben Kernproblem wie PEP 598 und PEP 602: Sie erzwingt Änderungen bei Endbenutzern, die mit dem Status quo zufrieden sind, ohne ihnen einen klaren kompensierenden Vorteil zu bieten.

Sie ist auch von einer der Hauptbedenken betroffen, die gegen PEP 598 vorgebracht wurden: Mindestens einige Core-Entwickler und Endbenutzer bevorzugen es nachdrücklich, dass keine bestimmte Semantik dem Wert einer der Zahlen in einer Release-Version zugewiesen wird. Diese Community-Mitglieder bevorzugen stattdessen, dass die gesamte semantische Bedeutung mit der Position innerhalb der Versionsnummer verbunden ist, die sich ändert.

Im Gegensatz dazu zielt der Rolling-Pre-Freeze-Release-Vorschlag darauf ab, dieses Anliegen zu adressieren, indem sichergestellt wird, dass sich die vorgeschlagenen Änderungen der Richtlinien alle darum drehen, ob eine bestimmte Version eine Alpha-Version, Beta-Version, Release Candidate oder finale Version ist.

Warum nicht Kalenderversionierung für den rollierenden Release-Stream verwenden?

Steve Dower's ursprüngliche Ausarbeitung dieses Vorschlags [1] schlug die Verwendung von Kalenderversionierung für den Rolling-Release-Stream vor (so dass die erste Rolling-Pre-Release nach Python 3.8.0 Python 2019.12 statt 3.9.0b1 gewesen wäre).

Paul Moore wies [2] auf zwei Hauptpraktische Probleme bei diesem Vorschlag hin:

• Für Benutzer von Kalender-basierten Versionen wird nicht klar sein, wo sie im Verhältnis zu den traditionell nummerierten Versionen stehen.
• Es bricht die Verarbeitung von Metadaten für Python-Requires in Packaging-Tools, ohne eine klare Möglichkeit zur zuverlässigen Behebung (da alle Kalenderversionen neuer als jede Standardversion erscheinen würden).

Diese PEP zielt darauf ab, beide Probleme durch die Verwendung der etablierten Beta-Versionsnummern für die Rolling-Releases zu lösen.

Betrachten Sie als Beispiel die folgende Frage: „Enthält Python 2021.12 alle neuen Funktionen, die in Python 3.9.0 veröffentlicht wurden?“. Mit Kalenderversionierung bei den Rolling-Releases ist dies ohne Konsultation eines Release-Kalenders nicht zu beantworten, um zu sehen, wann 3.9.0rc1 aus dem Rolling-Release-Stream ausgecheckt wurde.

Im Gegensatz dazu ist die äquivalente Frage für Rolling-Pre-Freeze-Releases einfach zu beantworten: „Enthält Python 3.10.0b2 alle neuen Funktionen, die in Python 3.9.0 veröffentlicht wurden?“. Allein durch die Formulierung der Frage ist die Antwort eindeutig „Ja, es sei denn, es waren provisorische Funktionen, die entfernt wurden“.

Der Beta-Nummerierungsansatz vermeidet auch andere Fragen, die sich aus dem Konzept der Kalenderversionierung ergeben, wie z. B. wie sys.version_info, PY_VERSION_HEX, die Benennung von site-packages-Verzeichnissen und die Benennung von installierten Python-Binärdateien und Erweiterungsmodulen funktionieren würden.

Wie würden Benutzer der rollierenden Pre-Freeze-Releases API-Änderungen erkennen?

Beim Hinzufügen neuer Funktionen werden Core-Entwickler dringend ermutigt, Feature-Erkennung und graceful Fallback auf alternative Ansätze über Mechanismen zu unterstützen, die nicht auf sys.version_info oder Laufzeit-Codeobjekt-Introspektion angewiesen sind.

In den meisten Fällen reicht eine einfache hasattr-Prüfung für das betroffene Modul aus, aber wenn dies nicht der Fall ist, werden alternative Ansätze als Teil der Feature-Addition betrachtet. Bisherige Vorgehensweisen in diesem Bereich umfassen das pickle.HIGHEST_PROTOCOL-Attribut, das hashlib.algorithms_available-Set und die verschiedenen os.supports_*-Sets, die das os-Modul bereits für plattformabhängige Fähigkeitserkennung bietet.

Es wäre auch möglich, Funktionen hinzuzufügen, die explizit über einen __future__-Import aktiviert werden müssen, wenn sie erstmals in die Rolling-Pre-Freeze-Releases aufgenommen werden, auch wenn dieser Feature-Flag nachträglich standardmäßig aktiviert wurde, bevor er zum ersten Mal in einem X.Y.0-Release Candidate erschien.

Die Begründung für diese Ansätze ist, dass explizite Erkennung/Aktivierung wie diese es Benutzern des Rolling-Pre-Freeze-Release-Streams erleichtern würde, zu bemerken, wenn wir provisorische Funktionen entfernen oder ändern (z. B. from __future__-Importe brechen bei der Kompilierung, wenn das Feature-Flag nicht mehr existiert) oder sicher auf frühere Funktionalität zurückzugreifen.

Die reiche Attributsuchmaschine des Interpreters bedeutet, dass wir auch Warnungen für provisorische oder veraltete Importe und Attribute hinzufügen können, für die wir keine praktischen Möglichkeiten haben, Prüfungen gegen den Wert von sys.version_info durchzuführen.

Warum eine neue Pre-Freeze-ABI-Flagge hinzufügen, um Recompilierungen nach X.Y.0rc1 zu erzwingen?

Das Kernentwicklungsteam rät derzeit aktiv von der Erstellung von öffentlich vorab kompilierten Binärdateien für eine X.Y-Serie vor dem ABI-Freeze-Datum ab.

Der Grund dafür ist, das Risiko schmerzhafter Debugging-Sitzungen bei der stabilen X.Y.0-Version zu vermeiden, die auf „Oh, unsere Abhängigkeit ‚superfast-binary-operation‘ war von einem CPython-ABI-Bruch in X.Y.0a3 betroffen, aber das Projekt hat seitdem keinen neuen Build veröffentlicht“ zurückzuführen sind.

Mit dem vorgeschlagenen Pre-Freeze-ABI-Flag ändert sich dieser Aspekt des Release-Adoptationsprozesses im Wesentlichen nicht vom Status quo: Eine neue CPython X.Y-Release-Serie erreicht den ABI-Freeze -> Paket-Maintainer veröffentlichen neue Binär-Erweiterungsmodule für diese Release-Serie -> Endbenutzer erhalten Segfaults nur aufgrund tatsächlicher Fehler, nicht nur durch Builds gegen eine inkompatible ABI.

Das Hauptziel des neuen Pre-Freeze-ABI-Flags ist es also, die Benutzererfahrung der Rolling-Pre-Freeze-Releases selbst zu verbessern, indem vorab kompilierte Binärarchive für diese Releases veröffentlicht werden können, ohne die Probleme zu riskieren, die uns derzeit dazu veranlassen, die Veröffentlichung von Binärartefakten vor dem ABI-Freeze aktiv abzuraten.

Im Idealfall müssen Paket-Maintainer nur einen Pre-Freeze-Binär-Build bei X.Y.0a1 veröffentlichen und dann einen Post-Freeze-Build nach X.Y.0rc1. Die einzigen Situationen, die in der Zwischenzeit einen Neuaufbau erfordern sollten, sind solche, bei denen das Projekt tatsächlich von einem CPython-ABI-Bruch in einer dazwischen liegenden Alpha-Version betroffen war.

Als konkretes Beispiel betrachten Sie das Szenario, in dem wir drei Releases haben, die ABI-Brüche beinhalten: X.Y.0a1, X.Y.0a5, X.Y.0a7. Die X.Y.0a7-ABI ist dann die ABI, die durch alle nachfolgenden Beta-Versionen und in X.Y.0rc1 fortgesetzt wird. (Dies ist das in Abbildung 1 dargestellte Szenario)

Jeden dazu zu zwingen, die Welt jedes Mal neu zu bauen, wenn es eine Alpha-Version im Rolling-Release-Stream gibt, würde fast sicher dazu führen, dass Publisher entscheiden, dass die Unterstützung der Rolling-Releases mehr Ärger als wert war, daher möchten wir zulassen, dass Module, die gegen X.Y.0a1 kompiliert wurden, gegen X.Y.0a7 geladen werden, da sie wahrscheinlich kompatibel sind (es gibt sehr wenige Projekte, die jede C-API nutzen, die CPython veröffentlicht, und die meisten ABI-Brüche betreffen eine einzelne spezifische API).

Sobald wir X.Y.0rc1 veröffentlichen, wollen wir jedoch sicherstellen, dass alle Binärdateien, die gegen X.Y.0a1 und X.Y.0a4 kompiliert wurden, vollständig aus der Endbenutzererfahrung entfernt werden. Es wäre schön, die Builds gegen X.Y.0a7 und alle nachfolgenden Beta-Versionen beibehalten zu können (da sich herausstellte, dass diese tatsächlich gegen die Post-Freeze-ABI gebaut wurden, auch wenn wir das damals nicht wussten), aber deren Verlust ist nicht schlimmer als der Status quo.

Das bedeutet, dass das Pre-Freeze-Flag „das Einfachste, was möglicherweise funktionieren kann“ ist, um dieses Problem zu lösen – es ist nur ein neues ABI-Flag, und wir haben bereits die Werkzeuge, um mit ABI-Flags umzugehen (sowohl im Interpreter als auch in den Werkzeugen zur Veröffentlichung und Installation von Paketen).

Da sich die ABI-Flags im Verhältnis zu den Vorabversionen geändert haben, müssen Projekte nicht einmal eine neue Version veröffentlichen: Sie können neue Wheel-Archive zu ihren bestehenden Releases hochladen, genau wie sie es heute können.

Ein clevereres Schema, das alles, was gegen die letzte Alpha- oder nachfolgenden Beta-Releases kompiliert wurde, retroaktiv akzeptieren konnte, wäre wahrscheinlich möglich, aber es wird nicht als notwendig für die Akzeptanz dieser PEP angesehen, da selbst wenn wir anfänglich mit einem einfachen Pre-Release-ABI-Flag beginnen, es immer noch möglich wäre, einen ausgefeilteren Ansatz für die Zukunft zu entwickeln.

Warum zusätzliche Alpha-Releases nach X.Y.0a1 zulassen?

In einer idealen Welt würden alle breaking changes an der vollständigen CPython-ABI in X.Y.0a1 zusammen mit den Dateisystem-Layout-Änderungen landen, und die ABI für die Release-Serie bliebe danach stabil.

Die jüngste Geschichte deutet jedoch nicht darauf hin, dass wir diese Verpflichtung eingehen und uns daran halten könnten, daher geht die PEP davon aus, dass ABI-Änderungen progressiv während der Pre-Freeze-Periode vorgenommen werden und der vollständige Lockdown erst mit der Erstellung des X.Y.z-Wartungszweigs bei der Vorbereitung von X.Y.0rc1 erfolgt.

Auswirkungen auf die CPython-Kernentwicklung

Die wichtigste Änderung für die CPython-Kernentwicklung ist die Notwendigkeit, den Master-Zweig konsistenter Release-ready zu halten.

Während die Hauptanforderung dafür wäre, die stabile BuildBot-Flotte grün zu halten, würde auch ermutigt, die Entwicklungsversion der Dokumentation für Benutzer der Rolling-Pre-Freeze-Releases aktuell zu halten. Dies wird die Bereitstellung von Entwürfen für „What’s New“-Einträge für Änderungen beinhalten, sobald diese implementiert sind, obwohl die anfänglichen Versionen relativ spärlich sein können und dann basierend auf Feedback von Beta-Release-Benutzern erweitert werden.

Für Core-Entwickler, die an der CPython C API arbeiten, gäbe es auch eine neue Anforderung, ABI-breaking Änderungen in ihren NEWS-Datei-Snippets konsistent zu markieren.

Zum spezifischen Thema der stabilen ABI können die meisten API-Designs einen Prozess durchlaufen, bei dem sie zuerst als provisorischer Teil der vollständigen CPython-API eingeführt werden (was Änderungen zwischen Pre-Freeze-Releases zulässt) und erst zur stabilen ABI befördert werden, sobald Entwickler zuversichtlich sind, dass die Schnittstelle tatsächlich stabil ist.

Nur in seltenen Fällen, in denen eine API außerhalb der stabilen ABI keinen Nutzen hat, kann es sinnvoll sein, eine Alpha-Version mit einer provisorischen stabilen ABI-Ergänzung zu veröffentlichen, anstatt das Design in der provisorischen CPython-API stattdessen zu iterieren.

Auswirkungen auf die Entwicklung von Python-Bibliotheken

Wenn diese PEP ihre Ziele erreicht, sollte die Unterstützung des Rolling-Pre-Freeze-Release-Streams für Bibliotheksautoren nicht wesentlich schmerzhafter sein als die Unterstützung der stabilen Releases.

Für Publisher von reinen Python-Paketen wäre dies eine Frage der Veröffentlichung von Wheel-Archiven mit dem Tag „py3“ und möglicherweise der Aufnahme des Rolling-Pre-Freeze-Release-Streams in ihre Testmatrix, wenn diese Option für sie verfügbar ist.

Für Publisher von Binär-Erweiterungsmodulen wäre die bevorzugte Option, die stabile C-ABI anzuzielen (sofern machbar) und somit eine ähnliche Erfahrung wie bei reinen Python-Paketen zu genießen, bei der ein einziges vorab kompiliertes Wheel-Archiv mehrere Python-Versionen, einschließlich des Rolling-Pre-Freeze-Release-Streams, abdecken kann.

Diese Option wird nicht für alle Bibliotheken praktikabel sein, und das gewünschte Ergebnis für diese Autoren ist, dass sie die Rolling-Releases unterstützen können, indem sie ein zusätzliches Wheel-Archiv erstellen und veröffentlichen, das gegen die erste X.Y.0a1-Version kompiliert wurde. Der nachfolgende Build gegen X.Y.0rc1 oder später ist dann derselbe Build, der benötigt worden wäre, wenn nur die endgültige stabile Version unterstützt worden wäre.

Zusätzliche Wheel-Builds über diese beiden hinaus sollten dann nur benötigt werden, wenn die betreffende Bibliothek direkt von einem ABI-Bruch in einer anderen Alpha-Version betroffen ist, die zwischen diesen beiden Punkten auftritt.

Ein verfügbarer Rolling-Pre-Freeze-Release-Stream könnte es auch mehr CI-Anbietern ermöglichen, eine „CPython Beta Release“-Testoption anzubieten. Derzeit ist diese Funktion nur von CI-Anbietern verfügbar, die bereit und in der Lage sind, die notwendige Zeit und Mühe in die Erstellung, Prüfung und Veröffentlichung ihrer eigenen Builds aus dem CPython-Master-Zweig zu investieren (z. B. [6]).

Auswirkungen auf die vorgeschlagene Support-Periode für das wissenschaftliche Python-Ökosystem

Basierend auf Diskussionen auf der SciPy 2019 wurde NEP (NumPy Enhancement Proposal) 29 [3] ausgearbeitet, um eine gemeinsame Konvention im Scientific-Python-Ökosystem für das Ablegen der Unterstützung älterer Python-Versionen vorzuschlagen.

Obwohl die genaue Formulierung dieser Richtlinie noch diskutiert wird, empfiehlt der Entwurf (Stand 20. Oktober 2019), dass Projekte jede Python-Feature-Version, die in den letzten 42 Monaten veröffentlicht wurde, unterstützen, wobei mindestens die beiden neuesten Python-Feature-Versionen unterstützt werden.

Für eine 18-monatige Feature-Release-Kadenz würde dies bedeuten, dass immer mindestens die beiden neuesten Feature-Releases unterstützt werden und die Unterstützung für alle X.Y.Z-Releases etwa 6 Monate nach der Veröffentlichung von X.(Y+2).0 eingestellt wird. Das bedeutet, dass es ungefähr alle zwei Jahre einen 6-monatigen Zeitraum gibt, in dem die drei neuesten Feature-Releases unterstützt werden.

Für eine 12-monatige Release-Kadenz würde dies bedeuten, dass immer mindestens die drei neuesten Feature-Releases unterstützt werden und die Unterstützung für alle X.Y.Z-Releases etwa 6 Monate nach der Veröffentlichung von X.(Y+3).0 eingestellt wird. Das bedeutet, dass für die Hälfte jedes Jahres die vier neuesten Feature-Releases unterstützt werden, während die andere Hälfte des Jahres hoffentlich genutzt wird, um sich auf die Feature-Release des Jahres vorzubereiten.

Für eine 24-monatige Release-Kadenz hat die zweite Klausel Vorrang vor der ersten, und die empfohlene Python-Versionsunterstützungsdauer erhöht sich auf 48 Monate ab der ursprünglichen X.Y.0-Veröffentlichung, um konsistent die beiden neuesten CPython-Feature-Releases zu unterstützen. Für Projekte, die auch den Rolling-Release-Stream unterstützen, erhöht sich die Anzahl der unterstützten Feature-Releases auf drei.

Abstimmung des Release-Zyklus auf Core-Entwicklungs-Sprints

Mit dem Vorschlag in dieser PEP wird erwartet, dass sich der Fokus der Kernentwicklungs-Sprints leicht verschiebt, abhängig vom aktuellen Zeitpunkt im zweijährigen Zyklus.

In Release-Jahren ist das Timing von PyCon US für neue Mitwirkende geeignet, um an Fehlerbehebungen und kleineren Features zu arbeiten, bevor der erste Release Candidate herauskommt, während sich die Language Summit und die Diskussionen der Core-Entwickler auf Pläne für die nächste Release-Serie konzentrieren können.

Der Pre-Alpha-Core-Development-Sprint in Release-Jahren bietet die Gelegenheit, Feedback zur vorherigen Version zu integrieren, entweder als Teil der nächsten Wartungsversion (für Fehlerbehebungen und Feedback zu provisorischen APIs) oder als Teil der ersten Alpha-Version der nächsten Release-Serie (für Feedback zu stabilen APIs).

Diese anfänglichen Alpha-Versionen wären auch das bevorzugte Ziel für ABI-breaking Änderungen an der vollständigen CPython-ABI (während Änderungen später im Release-Zyklus weiterhin wie in dieser PEP beschrieben zulässig wären, aber die Aufnahme in die X.Y.0a1-Version bedeutet, dass sie keine zusätzlichen Arbeiten für Publisher von vorab kompilierten Binärpaketen auslösen).

Die Wahlen zum Steering Council für den nächsten Release-Zyklus finden wahrscheinlich auch ungefähr zur gleichen Zeit wie die Pre-Alpha-Entwicklungssprints statt.

In Nicht-Release-Jahren würde sich der Fokus für beide Veranstaltungen nur auf die bevorstehenden Wartungs- und Pre-Freeze-Releases konzentrieren. Diese weniger intensiven Jahre würden hoffentlich eine Gelegenheit bieten, verschiedene Prozessänderungen und Infrastruktur-Upgrades anzugehen, ohne den Release-Candidate-Vorbereitungsprozess zu beeinträchtigen.

Abstimmung des Release-Zyklus auf prominente Linux-Distributionen

Einige Rolling-Release-Linux-Distributionen (z. B. Arch, Gentoo) sind möglicherweise in der Lage, die in diesem PEP vorgeschlagenen neuen Rolling-Pre-Freeze-Releases zu übernehmen, aber es wird erwartet, dass die meisten Distributionen weiterhin etablierte Releases verwenden.

Die in diesem PEP vorgeschlagenen spezifischen Daten für die endgültigen Veröffentlichungen wurden so gewählt, dass sie mit den Zeitplänen für den Feature Freeze für die jährlichen Oktober-Veröffentlichungen der Ubuntu- und Fedora-Linux-Distributionen übereinstimmen.

Für Fedora und Ubuntu bedeutet dies, dass die Release Candidate-Phase mit der Entwicklungsperiode für ein Distro-Release übereinstimmt, was der ideale Zeitpunkt für sie ist, eine neue Version zu testen und Feedback zu potenziellen Regressionen und Kompatibilitätsproblemen zu geben.

Für Ubuntu bedeutet dies auch, dass ihre April-LTS-Releases von einem vollständigen kurzfristigen Release-Zyklus mit der neuen System-Python-Version profitiert haben, während diese CPython-Version die meiste Zeit bis zur nächsten Ubuntu-LTS-Version für Upstream-Bugfixes offen bleibt.

Die einzige Ausrichtungsüberschneidung von Linux-Release-Zyklen, die mit dem spezifischen Vorschlag in diesem PEP wahrscheinlich durchweg schlecht ausfällt, ist mit Debian, da dieses seit 2005 in der ersten Jahreshälfte von ungeraden Jahren veröffentlicht wird (ungefähr 12 Monate versetzt zu den Ubuntu-LTS-Releases).

Mit dem jährlichen Release-Vorschlag in PEP 602 würden sowohl Debian als auch Ubuntu LTS konsistent eine System-Python-Version erhalten, die etwa 6 Monate alt ist, aber auch konsistent unterschiedliche Python-Versionen voneinander auswählen würden.

Mit einer zweijährlichen Kadenz und CPython-Releases in der zweiten Jahreshälfte werden sie wahrscheinlich dieselbe Version voneinander auswählen, aber eine von ihnen wird eine CPython-Version auswählen, die mehr als 18 Monate hinter den neuesten Beta-Releases zurückliegt, bis die Linux-Distribution ausgeliefert wird.

Wenn diese Situation eintritt und als unerwünscht erachtet wird (aber nicht so unerwünscht, dass Debian seinen Veröffentlichungszeitplan anpasst), dann ist es dort, wo die zusätzliche Komplexität des Vorschlags der „inkrementellen Feature-Releases“ in PEP 598 sich als lohnenswert erweisen könnte.

(Das Verschieben von CPython-Releases in die gleiche Jahreshälfte wie die Debian- und Ubuntu-LTS-Releases würde potenziell helfen, das Problem zu mildern, schafft aber auch neue Probleme, bei denen eine Verschiebung des CPython-Release-Zeitplans direkt den Release-Zeitplan einer Linux-Distribution beeinflussen könnte oder dazu führt, dass eine Distribution eine Python-Version ausliefert, die mehr als 18 Monate alt ist.)

Auswirkungen auf einfache Bereitstellungsumgebungen

Für die Zwecke dieses PEP ist eine „einfache“ Bereitstellungsumgebung jeder Anwendungsfall, bei dem es einfach ist sicherzustellen, dass alle Zielumgebungen auf eine neue Python-Version gleichzeitig (oder zumindest vor dem Rollout neuer übergeordneter Anwendungsversionen) aktualisiert werden, und jedes Pre-Release-Testing, das stattfindet, muss nur eine einzige Python-Mikroversion ansprechen.

Der einfachste Fall wäre das Scripting für den persönlichen Gebrauch, bei dem die Test- und Zielumgebungen genau dieselbe Umgebung sind.

Ähnlich einfache Umgebungen wären containerisierte Webdienste, bei denen derselbe Python-Container in der CI-Pipeline verwendet wird wie bei der Bereitstellung, und jede Anwendung, die ihre eigene Python-Runtime bündelt, anstatt sich auf eine bereits vorhandene Python-Bereitstellung auf dem Zielsystem zu verlassen.

Für diese Anwendungsfälle gibt es einen einfachen Mechanismus, um die Auswirkungen dieses PEP zu minimieren: Weiterhin die stabilen Releases verwenden und die Rolling-Pre-Freeze-Releases ignorieren.

Um die Rolling-Pre-Freeze-Releases in diesen Umgebungen tatsächlich zu übernehmen, wird die größte Herausforderung darin bestehen, das Potenzial für Segfaults von Erweiterungsmodulen zu handhaben, wenn die nächste Pre-Freeze-Version eine Alpha-Version und keine Beta-Version ist, was darauf hindeutet, dass die CPython-ABI möglicherweise auf inkompatible Weise geändert wurde.

Wenn alle verwendeten Erweiterungsmodule die stabile ABI ansprechen, dann gibt es kein Problem und alles funktioniert genauso reibungslos wie bei den stabilen Releases.

Alternativ könnte „alle Erweiterungsmodule neu kompilieren und zwischenspeichern“ zu einer Standardaktivität werden, die als Teil der Aktualisierung auf eine Alpha-Version durchgeführt wird.

Schließlich wäre es auch vernünftig, sich keine Sorgen darüber zu machen, bis etwas tatsächlich fehlschlägt, und es dann wie jedes andere Problem mit der Bibliothekskompatibilität zu behandeln, das bei einer neuen Alpha- oder Beta-Version gefunden wird.

Abgesehen von der ABI-Kompatibilität von Erweiterungsmodulen ist der andere Hauptpunkt zusätzlicher Komplexität bei der Verwendung der Rolling-Pre-Freeze-Releases die „Rollback“-Kompatibilität für unabhängig versionierte Features wie Pickle und SQLite, bei denen die Verwendung neuer oder vorläufiger Features im Beta-Stream Dateien erstellen kann, die von der stabilen Version nicht gelesen werden können. Anwendungen, die diese Arten von Features verwenden und auch die Fähigkeit benötigen, zuverlässig auf eine frühere stabile CPython-Version zurückzugreifen, wird, wie heute, geraten, die Verwendung von Vorabversionen zu vermeiden.

Auswirkungen auf komplexe Bereitstellungsumgebungen

Für die Zwecke dieses PEP sind „komplexe“ Bereitstellungsumgebungen Anwendungsfälle, die nicht die Kriterien für „einfache Bereitstellung“ erfüllen. Sie können mehrere verschiedene Python-Versionen, die Verwendung einer personalisierten Python-Version oder „Gatekeeper“ beinhalten, die die Verwendung einer neuen Version vor der Bereitstellung genehmigen müssen.

Zum Beispiel fallen Organisationen, die Python als Teil einer Standardbetriebsumgebung auf den Rechnern ihrer Benutzer installieren, in diese Kategorie, ebenso wie diejenigen, die eine Standard-Build-Umgebung bereitstellen. Distributionen wie conda-forge oder WinPython, die Sammlungen von konsistent gebauten und verifizierten Paketen anbieten, sind in ähnlicher Weise betroffen.

Diese Organisationen bevorzugen in der Regel entweder hohe Stabilität (z. B. alle, die glücklich die System-Python in einer stabilen Linux-Distribution wie Debian, RHEL/CentOS oder Ubuntu LTS als bevorzugte Python-Umgebung verwenden) oder schnelle Durchlaufzeiten (z. B. diejenigen, die regelmäßig zu den neuesten CPython-Vorabversionen beitragen).

In einigen Fällen können beide Nutzungsmodelle innerhalb derselben Organisation für unterschiedliche Zwecke existieren, wie zum Beispiel

• Verwendung einer stabilen Python-Umgebung für geschäftskritische Systeme, aber Datenwissenschaftlern die Nutzung der neuesten verfügbaren Version für ad-hoc-Datenanalysen zu ermöglichen
• ein Hardwarehersteller, der eine stabile Python-Version als Teil seiner Produktionsfirmware bereitstellt, aber die neueste verfügbare Version bei der Entwicklung und Ausführung seiner automatisierten Integrationstests verwendet

Unter jedem Release-Modell generiert jede neue Python-Version Arbeit für diese Organisationen. Diese Arbeit kann rechtliche, sicherheitstechnische oder technische Überprüfungen von Python selbst, Bewertung und Verifizierung von wirkungsvollen Änderungen, erneutes Anwenden von Patches, Neukompilieren und Testen von Drittanbieter-Abhängigkeiten und erst dann die Bereitstellung umfassen.

Organisationen, die Updates schnell übernehmen können, sollten in der Lage sein, die häufigeren Beta-Releases zu nutzen. Obwohl jede Aktualisierung immer noch ähnliche Ermittlungsarbeiten erfordert, wie sie heute erforderlich sind, sollte das Arbeitsvolumen pro Release reduziert werden, da jedes Release dem vorherigen ähnlicher sein wird als im aktuellen Modell. Ein Vorteil des vorgeschlagenen Modells mit monatlichen Releases ist, dass Organisationen ihre eigene Übernahmekadenz wählen können, von der Übernahme jedes Beta-Releases bis hin zur Übernahme eines pro Quartal, eines alle 6 Monate oder eines pro Jahr. Darüber hinaus wäre es wahrscheinlich sinnvoller, weiterhin die stabilen Releases zu verwenden.

Für Organisationen mit strengeren Bewertungen oder einer Präferenz für Stabilität wird der längere Release-Zyklus für stabile Releases den jährlichen Aufwand für Updates reduzieren, die längere Release-Candidate-Phase mehr Zeit für interne Tests vor dem X.Y.0-Release ermöglichen und die größere Nutzung durch andere während der Beta-Phase mehr Vertrauen in die anfänglichen Releases bieten. In der Zwischenzeit kann die Organisation mit Zuversicht durch Wartungsreleases für eine längere Zeit aufrüsten, ohne Angst vor Breaking Changes zu haben.