Zusammenfassung

Diese PEP legt Richtlinien für die Entwicklung von Python 3000 fest. Idealerweise einigen wir uns zuerst auf den Prozess und beginnen erst dann mit der Diskussion von Features, nachdem der Prozess entschieden und spezifiziert wurde. In der Praxis werden wir Features und Prozess gleichzeitig diskutieren; oft wird die Debatte über ein bestimmtes Feature eine Prozessdiskussion auslösen.

Benennung

Python 3000, Python 3.0 und Py3K sind alles Namen für dasselbe. Das Projekt heißt Python 3000 oder abgekürzt Py3k. Die tatsächliche Python-Veröffentlichung wird als Python 3.0 bezeichnet, und das wird „python3.0 -V“ ausgeben; die tatsächlichen Dateinamen werden die gleiche Namenskonvention verwenden, die wir für Python 2.x verwenden. Ich möchte keinen neuen Namen für die ausführbare Datei wählen oder die Endung für Python-Quelldateien ändern.

PEP-Nummerierung

Python 3000 PEPs beginnen mit der Nummerierung bei PEP 3000. PEPs 3000-3099 sind Meta-PEPs – dies können Prozess- oder Informations-PEPs sein. PEPs 3100-3999 sind Feature-PEPs. PEP 3000 selbst (diese PEP) ist besonders; sie ist die Meta-PEP für Python 3000 Meta-PEPs (d.h. sie beschreibt den Prozess zur Definition von Prozessen). PEP 3100 ist ebenfalls besonders; sie ist eine Liste von Features, die für (hoffentlich) die Aufnahme in Python 3000 ausgewählt wurden, bevor wir den Python 3000-Prozess richtig begonnen haben. PEP 3099 schließlich ist eine Liste von Features, die sich *nicht* ändern werden.

Zeitplan

Siehe PEP 361, die den Veröffentlichungsplan für Python 2.6 und 3.0 enthält. Diese Versionen werden gleichzeitig veröffentlicht.

Hinweis: Die Entwicklung der Standardbibliothek wird voraussichtlich nach der Veröffentlichung von 3.0a1 zunehmen.

Ich gehe davon aus, dass es eine Zeit lang parallele Veröffentlichungen von Python 2.x und 3.x geben wird; die Python 2.x-Veröffentlichungen werden länger fortgesetzt als die traditionellen 2.x.y Bugfix-Veröffentlichungen. Normalerweise hören wir auf, Bugfix-Versionen für 2.x zu veröffentlichen, sobald Version 2.(x+1) veröffentlicht wurde. Aber ich erwarte mindestens ein oder zwei neue 2.x-Veröffentlichungen sogar nach 3.0 (final), wahrscheinlich gut in 3.1 oder 3.2 hinein. Dies wird bis zu einem gewissen Grad von der Nachfrage der Community nach fortgesetztem 2.x-Support, der Akzeptanz und Stabilität von 3.0 sowie der Ausdauer der Freiwilligen abhängen.

Ich gehe davon aus, dass Python 3.1 und 3.2 viel früher nach 3.0 veröffentlicht werden, als es für die 2.x-Serie üblich war. Das 3.x-Veröffentlichungsmuster wird sich stabilisieren, sobald die Community mit 3.x zufrieden ist.

Kompatibilität und Übergang

Python 3.0 wird die Abwärtskompatibilität mit Python 2.x brechen.

Es besteht keine Anforderung, dass Python 2.6-Code unverändert unter Python 3.0 läuft. Nicht einmal ein Teilsatz. (Natürlich wird es einen *winzigen* Teilsatz geben, aber ihm wird wesentliche Funktionalität fehlen.)

Python 2.6 wird die Vorwärtskompatibilität auf folgende zwei Arten unterstützen

• Es wird einen „Py3k-Warnmodus“ unterstützen, der dynamisch (d.h. zur Laufzeit) vor Features warnt, die in Python 3.0 nicht mehr funktionieren werden, z.B. die Annahme, dass range() eine Liste zurückgibt.
• Es werden zurückportierte Versionen vieler Py3k-Features enthalten, entweder aktiviert durch __future__-Anweisungen oder einfach durch nebeneinanderstehende Verwendung von alter und neuer Syntax (wenn die neue Syntax in 2.x ein Syntaxfehler wäre).

Stattdessen und ergänzend zu den Vorwärtskompatibilitätsfeatures in 2.6 wird es ein separates Werkzeug zur Konvertierung von Quellcode geben [1]. Dieses Werkzeug kann eine kontextfreie Quell-zu-Quell-Übersetzung durchführen. Zum Beispiel kann es apply(f, args) in f(*args) übersetzen. Das Werkzeug kann jedoch keine Datenflussanalyse oder Typinferenz durchführen, daher nimmt es einfach an, dass sich apply in diesem Beispiel auf die alte eingebaute Funktion bezieht.

Das empfohlene Entwicklungsmodell für ein Projekt, das Python 2.6 und 3.0 gleichzeitig unterstützen muss, ist wie folgt:

0. Sie sollten exzellente Unit-Tests mit nahezu voller Abdeckung haben.
1. Portieren Sie Ihr Projekt nach Python 2.6.
2. Schalten Sie den Py3k-Warnmodus ein.
3. Testen und bearbeiten Sie, bis keine Warnungen mehr vorhanden sind.
4. Verwenden Sie das 2to3-Werkzeug, um diesen Quellcode in die 3.0-Syntax zu konvertieren. **Bearbeiten Sie die Ausgabe nicht manuell!**
5. Testen Sie den konvertierten Quellcode unter 3.0.
6. Wenn Probleme auftreten, nehmen Sie Korrekturen an der **2.6**-Version des Quellcodes vor und kehren Sie zu Schritt 3 zurück.
7. Wenn es Zeit für die Veröffentlichung ist, veröffentlichen Sie separate 2.6- und 3.0-Tarballs (oder welche Archivform auch immer Sie für Veröffentlichungen verwenden).

Es wird empfohlen, den 3.0-Quellcode nicht zu bearbeiten, bis Sie bereit sind, die 2.6-Unterstützung auf reine Wartung zu reduzieren (d.h. in dem Moment, in dem Sie den 2.6-Code normalerweise ohnehin auf einen Wartungszweig verschieben würden).

PS. Wir benötigen eine Meta-PEP, um die Übergangsprobleme im Detail zu beschreiben.

Implementierungssprache

Python 3000 wird in C implementiert, und die Implementierung wird aus der Evolution der Python 2-Codebasis abgeleitet. Dies spiegelt meine Ansichten (die ich mit Joel Spolsky teile [2]) über die Gefahren vollständiger Neufassungen wider. Da Python 3000 als Sprache eine relativ geringfügige Verbesserung gegenüber Python 2 ist, können wir viel gewinnen, indem wir nicht versuchen, die Sprache von Grund auf neu zu implementieren. Ich bin nicht gegen parallele Neuentwicklungsbemühungen, aber meine eigenen Bemühungen werden sich auf die Sprache und Implementierung richten, die ich am besten kenne.

Meta-Beiträge

Vorschläge für zusätzlichen Text für diese PEP werden vom Autor gerne entgegengenommen. Entwürfe von Meta-PEPs für die oben genannten Themen und zusätzliche Themen sind noch willkommen!

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.