Zuvor als veraltet markiert [erledigt]

PEP 4 listet alle Module auf, die in der stdlib als veraltet markiert wurden. Die angegebenen Motivationen spiegeln die in PEP 4 aufgeführten wider. Alle Module, die zum Zeitpunkt der ersten Alpha-Version von Python 3.0 in PEP aufgeführt sind, werden entfernt.

Der gesamte Inhalt von lib-old wird ebenfalls entfernt. Diese Module wurden bereits aus der Importierbarkeit entfernt, werden aber weiterhin zur Verteilung für Python für Benutzer, die auf den Code angewiesen sind, aufbewahrt.

• cfmfile
  • Seit Python 2.4 als veraltet dokumentiert, ohne expliziten Grund.
• cl
  • Seit Python 2.0 oder früher als veraltet dokumentiert.
  • Schnittstelle zur SGI-Hardware.
• md5
  • Ersetzt durch das Modul hashlib.
• mimetools
  • In einer früheren Version als veraltet dokumentiert.
  • Ersetzt durch das Paket email.
• MimeWriter
  • Ersetzt durch das Paket email.
• mimify
  • Ersetzt durch das Paket email.
• multifile
  • Ersetzt durch das Paket email.
• posixfile
  • Sperren werden besser mit fcntl.lockf() gehandhabt.
• rfc822
  • Ersetzt durch das Paket email.
• sha
  • Ersetzt durch das Paket hashlib.
• sv
  • Seit Python 2.0 oder früher als veraltet dokumentiert.
  • Schnittstelle zur veralteten SGI Indigo-Hardware.
• timing
  • Seit Python 2.0 oder früher als veraltet dokumentiert.
  • time.clock() bietet eine bessere Zeitauflösung.

Plattformspezifisch mit minimaler Nutzung [erledigt]

Python unterstützt viele Plattformen, von denen einige nicht weit verbreitet oder gepflegt werden. Und auf einigen dieser Plattformen gibt es Module, die für Benutzer auf diesen Plattformen nur begrenzt nützlich sind. Aufgrund ihrer begrenzten Nützlichkeit wäre es besser, das Python-Entwicklungsteam nicht länger mit ihrer Wartung zu belasten.

Die unten genannten Module sind dokumentiert. Alle undokumentierten Module für die angegebenen Plattformen werden ebenfalls entfernt.

Kaum genutzt [erledigt]

Einige plattformunabhängige Module werden selten verwendet. Dafür gibt es eine Reihe möglicher Erklärungen, darunter die einfache Neuimplementierung, ein sehr kleines Publikum oder mangelnde Einhaltung modernerer Standards.

• audiodev
  • Undokumentiert.
  • Seit fünf Jahren nicht mehr bearbeitet.
• imputil
  • Undokumentiert.
  • Nie aktualisiert, um absolute Imports zu unterstützen.
• mutex
  • Einfach zu implementieren mit einem Semaphor und einer Warteschlange.
  • Kann nicht auf einen Sperrversuch warten.
  • Seit seiner Einführung vor 15 Jahren nicht mehr einzigartig bearbeitet.
  • Nur nützlich mit dem Modul ‚sched‘.
  • Nicht Thread-sicher.
• stringold
  • Funktionsversionen der Methoden auf String-Objekten.
  • Veraltet seit Python 1.6.
  • Jegliche Funktionalität, die nicht im String-Objekt oder -Modul enthalten ist, wird in das String-Modul verschoben (hauptsächlich Konstanten).
• sunaudio
  • Undokumentiert.
  • Seit über sieben Jahren nicht mehr bearbeitet.
  • Das Modul sunau bietet ähnliche Funktionen.
• toaiff
  • Undokumentiert.
  • Erfordert die Installation der sox-Bibliothek auf dem System.
• user
  • Einfach zu handhaben, indem der Anwendung erlaubt wird, ihren eigenen Modulnamen anzugeben, die Existenz zu prüfen und bei Fund zu importieren.
• neu
  • Nur eine Neuzuordnung von Namen aus dem Modul ‚types‘.
  • Kann auch die integrierte Funktion type aufrufen, um die meisten Typen leicht zu erhalten.
  • Die Docstring besagt, dass das Modul seit Revision 27241 (2002-06-15) nicht mehr nützlich ist.
• pure
  • Geschrieben, bevor Pure Atria von Rational gekauft wurde, das dann von IBM gekauft wurde (mit anderen Worten, sehr alt).
• test.testall
  • Aus der Zeit vor regrtest.

Veraltet

Veraltet zu werden bedeutet, dass entweder ein anderes Modul in der stdlib oder eine weit verbreitete Drittanbieterbibliothek eine bessere Lösung für das Anwendungsgebiet des Moduls bietet.

• Bastion/rexec [erledigt]
  • Eingeschränkte Ausführung / Sicherheit.
  • In Python 2.3 deaktiviert.
  • Als unsicher eingestufte Module.
• bsddb185 [erledigt]
  • Ersetzt durch bsddb3
  • Nicht standardmäßig kompiliert.
  • Die Dokumentation besagt, dass das „Modul niemals direkt in neuem Code verwendet werden sollte“.
  • Extern verfügbar von PyPI.
• Canvas [erledigt]
  • Seit 2000 von Guido in einem Kommentar als veraltet markiert (siehe http://bugs.python.org/issue210677).
  • Es ist besser, die Tkinter.Canvas-Klasse zu verwenden.
• commands [erledigt]
  • Das subprocess-Modul ersetzt es (PEP 324).
  • Entferne getstatus(), verschiebe den Rest nach subprocess.
• compiler [erledigt]
  • Das gleichzeitige Warten des integrierten Compilers und des stdlib-Pakets ist redundant [17].
  • Die vom Compiler erstellte AST ist verfügbar [16].
  • Es muss ein Mechanismus zum Kompilieren aus einer AST hinzugefügt werden.
• dircache [erledigt]
  • Vernachlässigbare Nutzung.
  • Leicht zu replizieren.
• dl [erledigt]
  • ctypes bietet bessere Unterstützung für dieselbe Funktionalität.
• fpformat [erledigt]
  • Die gesamte Funktionalität wird durch String-Interpolation unterstützt.
• htmllib [erledigt]
  • Ersetzt durch HTMLParser.
• ihooks [erledigt]
  • Undokumentiert.
  • Zur Verwendung mit rexec, das seit Python 2.3 deaktiviert ist.
• imageop [erledigt]
  • Bessere Unterstützung durch Drittanbieterbibliotheken (Python Imaging Library [11]).

  • Unit-Tests basierten auf rgbimg und imgfile.

    • rgbimg wurde in Python 2.6 entfernt.
    • imgfile ist für die Entfernung in diesem PEP vorgesehen.

• linuxaudiodev [erledigt]
  • Ersetzt durch ossaudiodev.
• mhlib [erledigt]
  • Sollte als einzelnes Modul entfernt werden; stattdessen mailbox verwenden.
• popen2 [erledigt]
  • Das subprocess-Modul ersetzt es (PEP 324).
• sgmllib [erledigt]
  • Parst SGML nicht vollständig.
  • In der stdlib zur Unterstützung von htmllib, das zur Entfernung vorgesehen ist.
• sre [erledigt]
  • Zuvor als veraltet markiert; stattdessen re importieren.
• stat [TODO: Alle Verwendungen auf os.stat() umstellen]
  • os.stat() gibt nun ein Tupel mit Attributen zurück.
  • Die Funktionen im Modul sollten zu Methoden für das von os.stat zurückgegebene Objekt gemacht werden.
• statvfs [erledigt]
  • os.statvfs gibt nun ein Tupel mit Attributen zurück.
• thread [erledigt]
  • Leute sollten stattdessen ‚threading‘ verwenden.
    • ‚thread‘ in _thread umbenennen.
    • dummy_thread als veraltet markieren und _dummy_thread umbenennen.
    • thread.get_ident nach threading verschieben.
  • Guido hat die Deprekation zuvor unterstützt [8].
• urllib [erledigt]
  • Ersetzt durch urllib2.
  • Die ausschließlich urllib vorbehaltene Funktionalität wird im urllib-Paket beibehalten.
• UserDict [erledigt: 3.0] [TODO: 2.6 behandeln]
  • Nicht mehr so nützlich, da Typen eine Superklasse sein können.
  • Nützliche Teile wurden in das Modul ‚collections‘ verschoben.
• UserList/UserString [erledigt]
  • Nicht nützlich, da Typen eine Superklasse sein können.
  • In das Modul ‚collections‘ verschoben.

Wartungsaufwand

Im Laufe der Jahre sind bestimmte Module zu einer erheblichen Belastung für python-dev geworden. In solchen Fällen ist es besser, das Modul der Gemeinschaft zur Pflege zu überlassen, um python-dev zu entlasten, damit es sich stärker auf die Sprachunterstützung und andere Module in der Standardbibliothek konzentrieren kann, die nicht übermäßig viel Zeit und Mühe beanspruchen.

• bsddb3
  • Extern gepflegt unter http://www.jcea.es/programacion/pybsddb.htm .
  • Konsistente Testinstabilität.
  • Berkeley DB folgt einem anderen Release-Zeitplan als Python, was dazu führt, dass die Bindings nicht unbedingt mit dem verfügbaren Stand synchronisiert sind.

PEP 8-Verstöße [erledigt]

PEP 8 schreibt vor, dass Module „kurze, durchgehend kleingeschriebene Namen haben sollten“, bei denen „Unterstriche verwendet werden können ..., wenn dies die Lesbarkeit verbessert“. Die Verwendung von Unterstrichen wird in Paketnamen nicht empfohlen. Die folgenden Module verstoßen gegen PEP 8 und werden nicht auf andere Weise umbenannt, indem sie in ein Paket verschoben werden.

Zusammenführen von C- und Python-Implementierungen derselben Schnittstelle

Mehrere Schnittstellen haben sowohl eine Python- als auch eine C-Implementierung. Während es großartig ist, eine C-Implementierung für Geschwindigkeit mit einer Python-Implementierung als Fallback zu haben, gibt es keinen Grund, die beiden Implementierungen unabhängig voneinander in der stdlib offenzulegen. Für Python 3.0 werden alle Schnittstellen mit zwei Implementierungen zu einer einzigen öffentlichen Schnittstelle zusammengeführt.

Das C-Modul erhält einen führenden Unterstrich, um zu kennzeichnen, dass es nicht die Referenzimplementierung ist (die Python-Implementierung ist dies). Das bedeutet, dass alle semantischen Unterschiede zwischen der C- und der Python-Version vor Python 3.0 behandelt werden müssen, oder die C-Implementierung wird entfernt, bis sie behoben ist.

Eine Schnittstelle, die unten nicht aufgeführt ist, ist xml.etree.ElementTree. Dies ist ein extern gepflegtes Modul und liegt daher nicht in der direkten Kontrolle des Python-Entwicklungsteams für die Umbenennung. Siehe Offene Fragen für eine Diskussion darüber.

• pickle/cPickle [erledigt]
  • cPickle in _pickle umbenennen.
  • Semantische Vollständigkeit der C-Implementierung *nicht* verifiziert.
• profile/cProfile [TODO]
  • cProfile in _profile umbenennen.
  • Semantische Vollständigkeit der C-Implementierung *nicht* verifiziert.
• StringIO/cStringIO [erledigt]
  • Die Klasse zum Modul ‚io‘ hinzufügen.

Keine öffentliche, dokumentierte Schnittstelle [erledigt]

Es gibt mehrere Module in der stdlib, die keine definierte öffentliche Schnittstelle haben. Diese Module existieren als Support-Code für andere Module, die offengelegt werden. Da sie nicht direkt verwendet werden sollen, sollten sie umbenannt werden, um dies widerzuspiegeln.

Schlecht gewählte Namen [erledigt]

Einige Module haben Namen, die im Nachhinein schlecht gewählt wurden. Sie sollten umbenannt werden, um zu verhindern, dass ihr schlechter Name über die 2.x-Serie hinaus Bestand hat.

Gruppierung von Modulen [erledigt]

Mit dem Wachstum der stdlib haben sich mehrere Bereiche erweitert und mehrere Module aufgenommen (z. B. Unterstützung für Datenbankdateien). Es ist daher sinnvoll, zusammengehörige Module in Pakete zu gruppieren.

Probleme

Themen im Zusammenhang mit diesem PEP

• Problem 2775: Master-Tracking-Problem
• Problem 2828: cleanup undoc.rst

Für zu entfernende Module

Für die Modulentfernungen ist es am einfachsten, das Modul zuerst in Python 3.0 zu entfernen, um zu sehen, wo Abhängigkeiten bestehen. Dies erleichtert das Auffinden von Code, der (möglicherweise) die Unterdrückung der DeprecationWarning erfordert.

Umbenennung von Modulen

Die Unterstützung im 2to3-Refactoring-Tool für Umbenennungen wird verwendet, um Benutzern den Übergang zu neuen Modulnamen zu erleichtern [9]. Import-Anweisungen werden neu geschrieben, so dass nur die Import-Anweisung und kein anderer Teil des Codes berührt werden muss. Dies wird durch die Verwendung des Schlüsselworts as in Import-Anweisungen erreicht, um im Modul-Namespace unter dem alten Namen zu binden, während basierend auf dem neuen Namen importiert wird (wenn das Schlüsselwort nicht bereits verwendet wird, dann wird der neu zugewiesene Name unverändert gelassen und nur das importierte Modul muss geändert werden). Der Fixer fix_imports ist ein Beispiel für die Vorgehensweise.

Umbenennung von Modulen, die außerhalb der Standardbibliothek gepflegt werden

xml.etree.ElementTree erfüllt nicht nur die PEP 8-Namensstandards, sondern hat auch eine offengelegte C-Implementierung. Es ist ein extern gepflegtes Paket, obwohl PEP 360. Es wird eine Anfrage an den Maintainer gestellt, den Namen zu ändern, damit er PEP 8 entspricht und die C-Implementierung verbirgt.

Module, die ursprünglich zur Entfernung vorgeschlagen wurden

• asynchat/asyncore
  • Josiah Carlson hat erklärt, dass er die Module pflegen wird.
• audioop/sunau/aifc
  • Audio-Module, bei denen die Formate noch verwendet werden.
• base64/quopri/uu
  • Alle immer noch weit verbreitet.
  • Das Modul ‚codecs‘ bietet keine so schöne API für grundlegende Nutzung.
• fileinput
  • Nützlich, wenn man mit stdin arbeiten muss.
• linecache
  • Wird intern an mehreren Stellen verwendet.
• nis
  • Zeugenaussagen von Personen, dass NIS-Neuinstallationen immer noch stattfinden
• getopt
  • Einfacher als optparse.
• repr
  • Nützlich als Grundlage für Überschreibungen.
  • Intern verwendet.
• sched
  • Nützlich für Simulationen.
• symtable/_symtable
  • Docs wurden geschrieben.
• telnetlib
  • Sehr praktisch für schnelle und schmutzige Fernzugriffe.
  • Einige Hardware unterstützt die Verwendung von Telnet für Konfiguration und Abfragen.
• Tkinter
  • Würde die Existenz von IDLE verhindern.
  • Kein GUI-Toolkit wäre out-of-the-box verfügbar.

Einführung eines neuen Top-Level-Pakets

Es wurde vorgeschlagen, die gesamte stdlib in ein eigenes Paket zu legen. Dieses PEP wird sich nicht mit dieser Frage befassen, da es eigene Designprobleme hat (Benennung, verdient es besondere Berücksichtigung in Import-Semantik usw.). Alles in diesem PEP kann leicht gehandhabt werden, wenn ein neues Top-Level-Paket eingeführt wird.

Einführung neuer Pakete zur Aufnahme von themenbezogenen Modulen

Während der Erstellung dieses PEP wurde festgestellt, dass bestimmte Themen in der stdlib auftraten. In der Vergangenheit haben Leute vorgeschlagen, neue Pakete einzuführen, um Module zu sammeln, die ein ähnliches Thema teilen (z. B. Audio). Ein offenes Problem wurde erstellt, um einige neue Pakete vorzuschlagen.

Am Ende konnte jedoch nicht genügend Unterstützung gewonnen werden, um die Idee weiterzuverfolgen. Stattdessen wurde die Namensvereinfachung als Leitprinzip für PEPs gewählt.