Zusammenfassung

Diese PEP beschreibt ein Verfahren zur Überprüfung und Verbesserung von Standardbibliotheksmodulen, insbesondere solcher, die in Python geschrieben sind, um sie für Python 3000 vorzubereiten. Es kann verschiedene Schritte der Überarbeitung geben, die jeweils in einem Abschnitt unten beschrieben werden. Natürlich muss nicht jeder Schritt für jedes Modul durchgeführt werden.

Entfernung veralteter Module

Alle Module, die in Python 2.x-Versionen als veraltet markiert sind, sollten für Python 3000 entfernt werden. Dasselbe gilt für Module, die heute als veraltet angesehen werden, aber zu weit verbreitet sind, um sie als veraltet zu markieren oder zu entfernen. Python 3000 ist die große Gelegenheit, sie loszuwerden.

Es wird ein Dokument erforderlich sein, das alle entfernten Module auflistet, zusammen mit Informationen über mögliche Ersatz oder Alternativen. Diese Informationen müssen auch vom Portierungs-Hilfsskript python3warn.py bereitgestellt werden, das in PEP XXX erwähnt wird.

Umbenennung von Modulen

Es gibt Vorschläge für eine "große stdlib-Umbenennung", die einen hierarchischen Namensraum für die Bibliothek oder ein Top-Level-Paket einführt, von dem aus Standardmodule importiert werden können. Abgesehen von dieser Möglichkeit ist bekannt, dass einige Modulnamen unglücklich gewählt wurden, ein Fehler, der in der 2.x-Serie nie korrigiert werden konnte. Beispiele sind Namen wie "StringIO" oder "Cookie". Für Python 3000 wird die Möglichkeit bestehen, diesen Modulen weniger verwirrende und konformere Namen zu geben.

Selbstverständlich muss jede Umbenennung in der Dokumentation des jeweiligen Moduls und vielleicht im globalen Dokument von Schritt 1 angegeben werden. Zusätzlich wird das Skript python3warn.py die alten Modulnamen erkennen und den Benutzer entsprechend benachrichtigen.

Wenn die Namensänderung rechtzeitig für eine weitere Veröffentlichung der Python 2.x-Serie erfolgt, lohnt es sich, die Einführung des neuen Namens im 2.x-Zweig in Betracht zu ziehen, um den Übergang zu erleichtern.

Code-Bereinigung

Da die meisten Bibliotheksmodule, die in Python geschrieben sind, bis auf Fehlerbehebungen nicht angefasst wurden, nach der Politik, ein laufendes System nie zu ändern, enthalten viele von ihnen möglicherweise Code, der nicht die neuesten Sprachfunktionen nutzt und in einem prägnanteren, moderneren Python neu geschrieben werden könnte.

PyChecker sollte das Modul sauber durchlaufen. Mit einer sorgfältig abgestimmten Konfigurationsdatei sollte PyLint ebenfalls so wenige Warnungen wie möglich ausgeben.

Solange diese Änderungen die Schnittstelle und das Verhalten des Moduls nicht ändern, sind keine Dokumentationsaktualisierungen erforderlich.

Verbesserung der Test- und Dokumentationsabdeckung

Die Code-Abdeckung durch Unit-Tests variiert stark zwischen den Modulen. Jede Testsuite sollte auf Vollständigkeit geprüft werden, und die verbleibenden klassischen Tests sollten in PyUnit (oder ein beliebiges neues, glänzendes Testframework, das mit Python 3000 kommt, vielleicht py.test?) konvertiert werden.

Es sollte auch überprüft werden, ob jede öffentlich sichtbare Funktion einen aussagekräftigen Docstring hat, der idealerweise mehrere Doctests enthält.

Für die Verbesserung der Testabdeckung sind keine Dokumentationsänderungen erforderlich.

Vereinheitlichung von Modulmetadaten

Dies ist ein kleiner und wahrscheinlich nicht sehr wichtiger Schritt. Es gab verschiedene Versuche, Autoren-, Versions- und ähnliche Metadaten in Modulen bereitzustellen (wie z. B. ein globales "__version__"). Diese könnten standardisiert und in der gesamten Bibliothek verwendet werden.

Auch für diesen Schritt sind keine Dokumentationsänderungen erforderlich.

Abwärtsinkompatible Fehlerbehebungen

Im Laufe der Jahre wurden viele Fehlermeldungen eingereicht, die sich über Fehler in Standardbibliotheksmodulen beschwerten, aber anschließend als "Wird nicht behoben" geschlossen wurden, da eine Behebung eine größere Inkompatibilität eingeführt hätte, die für die Python 2.x-Serie nicht akzeptabel war. In Python 3000 kann die Behebung angewendet werden, wenn die Schnittstelle an sich noch akzeptabel ist.

Jede geringfügige Verhaltensänderung, die durch solche Korrekturen verursacht wird, muss in der Dokumentation erwähnt werden, vielleicht in einem Absatz "Geändert in Version 3.0".

Schnittstellenänderungen

Die letzte und störendste Änderung ist die Überarbeitung der öffentlichen Schnittstelle eines Moduls. Wenn die Schnittstelle eines Moduls geändert werden soll, sollte zuvor eine Begründung geliefert oder eine PEP geschrieben werden.

Die Änderung muss vollständig als "Neu in Version 3.0" dokumentiert werden, und das Skript python3warn.py muss darüber Bescheid wissen.

Referenzen

Noch keine.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.