Zusammenfassung

Dieses PEP beschreibt das Verfahren für Änderungen an Python, die zwischen der Python 2.X-Serie und Python 3000 abwärtsinkompatibel sind. Alle derartigen Änderungen müssen durch ein entsprechendes Python 3000 PEP dokumentiert werden und müssen von Code begleitet werden, der identifizieren kann, wann Python 2.X-Code in Python 3000 problematisch sein könnte.

Begründung

Python 3000 wird eine Reihe von abwärtsinkompatiblen Änderungen an Python einführen, hauptsächlich um die Sprache zu straffen und einige frühere Designfehler zu beheben. Python 3000 soll jedoch keine neue und völlig andere Sprache als die Python 2.X-Serie sein, und es wird erwartet, dass ein Großteil der Python-Benutzergemeinschaft den Übergang zu Python 3000 vollziehen wird, sobald es verfügbar ist.

Um diesen Übergang zu fördern, ist es entscheidend, eine klare und vollständige Anleitung zur Aktualisierung von Python 2.X-Code auf Python 3000-Code bereitzustellen. Daher sind für jede abwärtsinkompatible Änderung zwei Dinge erforderlich:

• Ein offizielles Python Enhancement Proposal (PEP)
• Code, der Python 2.X-Code identifizieren kann, der in Python 3000 problematisch sein könnte

Python Enhancement Proposals

Jede abwärtsinkompatible Änderung muss von einem PEP begleitet werden. Dieses PEP sollte den üblichen PEP-Richtlinien folgen und den Zweck und die Begründung hinter der abwärtsinkompatiblen Änderung erläutern. Zusätzlich zu den üblichen PEP-Abschnitten müssen alle PEPs, die abwärtsinkompatible Änderungen vorschlagen, einen zusätzlichen Abschnitt enthalten: Kompatibilitätsprobleme. Dieser Abschnitt sollte beschreiben, was an der vorgeschlagenen Änderung für Python abwärtsinkompatibel ist und welche Hauptarten von Brüchen zu erwarten sind.

Obwohl PEPs weiterhin von Fall zu Fall bewertet werden müssen, kann ein PEP für Python 3000 ungeeignet sein, wenn sein Abschnitt "Kompatibilitätsprobleme" eines der folgenden impliziert:

• Die meisten oder alle Instanzen eines Python 2.X-Konstrukts sind in Python 3000 falsch, und die meisten oder alle Instanzen des Python 3000-Konstrukts sind in Python 2.X falsch.

  Zum Beispiel würde die Änderung der Bedeutung der for-Schleifen-else-Klausel von "ausgeführt, wenn die Schleife nicht unterbrochen wurde" zu "ausgeführt, wenn die Schleife null Iterationen hatte" bedeuten, dass alle Python 2.X for-Schleifen-else-Klauseln kaputt wären und es keine Möglichkeit gäbe, eine for-Schleifen-else-Klausel in einer für Python 3000 geeigneten Weise zu verwenden. Daher würde ein PEP für eine solche Idee wahrscheinlich abgelehnt.

• Viele Instanzen eines Python 2.X-Konstrukts sind in Python 3000 falsch, und das PEP zeigt keine realen Anwendungsfälle für die Änderungen.

  Abwärtsinkompatible Änderungen sind in Python 3000 erlaubt, aber nicht im Übermaß. Ein PEP, das abwärtsinkompatible Änderungen vorschlägt, sollte gute Beispiele für Code liefern, der sichtbar von den Änderungen profitiert.

Das Verfassen von PEPs ist zeitaufwendig. Wenn eine Reihe von abwärtsinkompatiblen Änderungen eng miteinander verbunden sind, sollten sie in demselben PEP vorgeschlagen werden. Solche PEPs werden wahrscheinlich längere Abschnitte über Kompatibilitätsprobleme haben, da sie nun die Art von Brüchen beschreiben müssen, die von *allen* vorgeschlagenen Änderungen zu erwarten sind.

Identifizierung problematischer Code

Zusätzlich zur PEP-Anforderung müssen abwärtsinkompatible Änderungen an Python auch von Code begleitet werden, der Warnungen für Python 2.X-Code ausgibt, der sich in Python 3000 anders verhält. Solche Warnungen werden in Python 2.X mit einem neuen Befehlszeilenschalter aktiviert: -3. Alle abwärtsinkompatiblen Änderungen sollten von einem Patch für Python 2.X begleitet werden, der bei Angabe von -3 Warnungen für jede Konstruktion ausgibt, die geändert wird.

Wenn beispielsweise dict.keys() in Python 3000 einen Iterator zurückgibt, sollte der Patch für den Python 2.X-Zweig etwas wie folgt tun:

Wenn -3 angegeben wurde, ändern Sie dict.keys() so, dass eine Unterklasse von list zurückgegeben wird, die Warnungen ausgibt, wann immer Sie andere Methoden als __iter__() verwenden.

Ein solcher Patch würde bedeuten, dass Warnungen nur ausgegeben werden, wenn Funktionen verwendet werden, die in Python 3000 nicht vorhanden sein werden, und fast aller bestehende Code weiterhin funktionieren sollte. (Code, der davon abhängt, dass dict.keys() immer eine list und keine Unterklasse zurückgibt, sollte so gut wie nicht existieren.)

Referenzen

TBD

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.