PEP 3003 – Python Language Moratorium

Autor:: Brett Cannon, Jesse Noller, Guido van Rossum
Status:: Final
Typ:: Prozess
Erstellt:: 21-Okt-2009
Post-History:: 03-Nov-2009

Inhaltsverzeichnis

Zusammenfassung
Begründung
Details
Rückwirkend
Erweiterungen
Urheberrecht
Referenzen

Zusammenfassung

Dieser PEP schlägt ein temporäres Moratorium (Aussetzung) aller Änderungen an der Python-Sprachsyntax, -semantik und -builtins für einen Zeitraum von mindestens zwei Jahren ab der Veröffentlichung von Python 3.1 vor. Insbesondere würde das Moratorium Python 3.2 (das 18-24 Monate nach 3.1 veröffentlicht werden soll) umfassen, aber Python 3.3 (vorausgesetzt, es wird nicht vorzeitig veröffentlicht) wieder Sprachänderungen aufnehmen lassen.

Diese Aussetzung von Funktionen soll nicht-CPython-Implementierungen ermöglichen, mit der Kernimplementierung der Sprache „aufzuholen“, die Einführung von Python 3.x erleichtern und eine stabilere Basis für die Community bieten.

Begründung

Diese Idee wurde von Guido van Rossum auf der Mailingliste python-ideas [1] vorgeschlagen. Die Prämisse seiner E-Mail war, die Änderung der Python-Kernsyntax, der Builtins und der Semantik zu verlangsamen, damit nicht-CPython-Implementierungen mit dem aktuellen Stand von Python, sowohl 2.x als auch 3.x, aufholen können.

Python ist als Sprache mehr als nur die Kernimplementierung – CPython – mit einer reichen, ausgereiften und lebendigen Community von Implementierungen wie Jython [2], IronPython [3] und PyPy [4], die nicht nur der Community, sondern auch der Sprache selbst zugutekommen.

Wiederum andere, wie Unladen Swallow [5] (ein Zweig von CPython), streben nicht danach, eine alternative Implementierung zu schaffen, sondern die Leistung und Implementierung von CPython selbst zu verbessern.

Python 3.x war ein großer Teil der Entwicklung von Python in den letzten Jahren. Seine Veröffentlichung sowie eine Fülle von Änderungen an der Sprache, die dadurch und durch die vorherigen 2.6.x-Releases eingeführt wurden, bringen alternative Implementierungen in „Schritt zu halten“ mit der Kernentwicklung von Python in einen erheblichen Nachteil.

Darüber hinaus haben viele der in den letzten Releases der von CPython implementierten Sprache vorgenommenen Änderungen noch keine breite Nutzung durch die allgemeine Benutzerpopulation erfahren. Die meisten Benutzer sind beispielsweise auf die Version des Interpreters (typischerweise CPython) beschränkt, die mit ihrem Betriebssystem vorinstalliert ist. Die meisten OS-Anbieter beginnen gerade erst, Python 2.6 auszuliefern – noch weniger liefern Python 3.x aus.

Da erwartet wird, dass Python 2.7 das effektive „End of Life“ der Python 2.x-Codezeile ist und Python 3.x die Zukunft darstellt, liegt es im besten Interesse der Kernentwicklung von Python, die Änderung der Sprache selbst vorübergehend auszusetzen, damit all diese externen Einheiten aufholen können und die Einführung sowie Migration zu Python 3.x unterstützt wird.

Schließlich soll das Moratorium die Kernentwicklungsressourcen entlasten, um sich auf andere Probleme zu konzentrieren, wie z. B. den CPython-Interpreter und dessen Verbesserungen, die Standardbibliothek usw.

Dieses Moratorium sieht keine Ausnahmen vor – sobald angenommen, werden alle ausstehenden Änderungen an der Syntax oder Semantik der Sprache verschoben, bis das Moratorium aufgehoben ist.

Dieses Moratorium gilt nicht für andere Python-Implementierungen, d.h. dass andere Implementierungen bei Bedarf Funktionen hinzufügen können, die von der Standardimplementierung abweichen.

Details

Nicht änderbar

Neue Built-ins
Sprachsyntax
Die Grammatikdatei wird im Wesentlichen unveränderlich, abgesehen von Behebungen von Mehrdeutigkeiten.
Allgemeine Sprachsemantik
Die Sprache funktioniert wie bisher, nur mit spezifischen Ausnahmen (siehe unten).
Neue `__future__`-Importe
Diese sind ausdrücklich verboten, da sie die Sprachsyntax und/oder -semantik effektiv ändern (wenn auch mithilfe einer Compiler-Direktive).

Ausnahmen im Einzelfall

Neue Methoden für Built-ins
Es kann ein Fall für das Hinzufügen einer Methode zu einem Built-in-Objekt gemacht werden.
Fehlerhafte Sprachsemantik
Wenn sich die Sprachsemantik als mehrdeutig oder schlecht implementiert herausstellt, basierend auf der ursprünglichen Designabsicht, kann die Semantik geändert werden.
Sprachsemantik, die schwer zu implementieren ist
Da andere VMs noch nicht mit der Implementierung der Python 3.x-Semantik begonnen haben, besteht die Möglichkeit, dass bestimmte Semantiken zu schwierig zu reproduzieren sind. In diesen Fällen können sie geändert werden, um die Einführung von Python 3.x durch die anderen VMs zu erleichtern.

Änderbar

C API
Es ist völlig akzeptabel, den zugrunde liegenden C-Code von CPython zu ändern, solange andere Beschränkungen dieses Moratoriums nicht verletzt werden. Z.B. wäre das Entfernen des GIL in Ordnung, vorausgesetzt, bestimmte Operationen, die derzeit atomar sind, bleiben atomar.
Die Standardbibliothek
Da die Standardbibliothek nicht direkt an die Sprachdefinition gebunden ist, fällt sie nicht unter dieses Moratorium.
Backports von 3.x-Features zu 2.x
Das Moratorium betrifft nur Features, die neu in 3.x wären.
Importsemantik
Zum Beispiel PEP 382. Immerhin variiert die Importsemantik zwischen Python-Implementierungen ohnehin.

Rückwirkend

Es ist wichtig zu beachten, dass das Moratorium alle Änderungen seit der Veröffentlichung von Python 3.1 abdeckt. Diese Regel soll verhindern, dass Features während der Diskussion des Moratoriums überstürzt oder in den CPython-Quellbaum eingeschleust werden. Eine Überprüfung der NEWS-Datei für den py3k-Entwicklungszweig ergab, dass keine Commits zurückgerollt werden müssten, um dieses Ziel zu erreichen.