Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 594 – Entfernen von Batterien, die in der Standardbibliothek nicht mehr benötigt werden

Autor:
Christian Heimes <christian at python.org>, Brett Cannon <brett at python.org>
Discussions-To:
Discourse thread
Status:
Final
Typ:
Standards Track
Erstellt:
20. Mai 2019
Python-Version:
3.11
Post-History:
21. Mai 2019, 04. Feb. 2022
Resolution:
Discourse-Nachricht

Inhaltsverzeichnis

Zusammenfassung

Dieses PEP schlug eine Liste von Modulen der Standardbibliothek vor, die aus der Standardbibliothek entfernt werden sollen. Die Module sind meist historische Datenformate (z. B. Commodore- und SUN-Dateiformate), APIs und Betriebssysteme, die längst abgelöst wurden (z. B. Mac OS 9) oder Module mit Sicherheitsimplikationen und besseren Alternativen (z. B. Passwort und Login).

Das PEP tritt in die Fußstapfen anderer PEPs wie PEP 3108. Der Vorschlag zur Standard Library Reorganization entfernte eine Reihe von Modulen aus Python 3.0. Im Jahr 2007 verwies das PEP auf die Wartungsbelastung als

„Im Laufe der Jahre sind bestimmte Module zu einer schweren Last für die Python-Entwicklung geworden. In solchen Fällen ist es besser, dass das Modul der Gemeinschaft zur Wartung überlassen wird, um die Python-Entwicklung zu entlasten, damit sie sich stärker auf die Sprachunterstützung und andere Module in der Standardbibliothek konzentrieren kann, die nicht unverhältnismäßig viel Zeit und Mühe in Anspruch nehmen.“

Das zurückgezogene PEP 206 aus dem Jahr 2000 drückt Probleme mit der Python-Standardbibliothek unverblümt und offen aus

„[...] die Module der Standardbibliothek sind nicht immer die beste Wahl für eine Aufgabe. Einige Bibliotheksmodule waren schnelle Hacks (z. B. calendar, commands), einige waren schlecht konzipiert und sind jetzt kaum noch zu reparieren (cgi) und einige sind durch andere, vollständigere Module obsolet geworden [...].“

Begründung

Früher wurde der Interpreter mit einer großen Sammlung nützlicher Module geliefert. Dies wurde oft als „Batterien inklusive“-Philosophie bezeichnet und war einer der Eckpfeiler des Erfolgs von Python. Benutzer mussten nicht herausfinden, wie sie separate Pakete herunterladen und installieren konnten, um einen einfachen Webserver zu schreiben oder E-Mails zu parsen.

Die Zeiten haben sich geändert. Mit der Einführung von PyPI (früher Cheeseshop), setuptools und später pip wurde das Herunterladen und Installieren von Paketen einfach und unkompliziert. Heutzutage verfügt Python über ein reiches und lebendiges Ökosystem von Drittanbieterpaketen. Es ist ziemlich üblich, Pakete von PyPI zu installieren oder eine der vielen Python- oder Linux-Distributionen zu verwenden.

Andererseits häufen sich in der Standardbibliothek von Python Altlasten, unnötige Duplizierung von Funktionalität und entbehrliche Funktionen. Dies ist aus mehreren Gründen unerwünscht.

  • Jedes zusätzliche Modul erhöht die Wartungskosten für das Kernentwicklungsteam von Python. Das Team hat begrenzte Ressourcen, reduzierte Wartungskosten setzen Entwicklungszeit für andere Verbesserungen frei.
  • Module in der Standardbibliothek werden im Allgemeinen bevorzugt und als De-facto-Lösung für ein Problem angesehen. Eine Mehrheit der Benutzer wählt Drittanbieter-Module nur dann, um ein Standardbibliotheksmodul zu ersetzen, wenn es einen zwingenden Grund gibt, z. B. lxml anstelle von xml. Die Entfernung eines nicht gewarteten Standardbibliotheksmoduls erhöht die Wahrscheinlichkeit, dass ein von der Community beigesteuertes Modul weit verbreitet wird.
  • Eine schlanke Standardbibliothek kommt Plattformen mit begrenzten Ressourcen zugute, wie Geräten mit nur wenigen hundert Kilobyte Speicherplatz (z. B. BBC Micro:bit). Python auf mobilen Plattformen wie BeeWare oder WebAssembly (z. B. Pyodide) profitiert ebenfalls von einer reduzierten Downloadgröße.

Die Module in diesem PEP wurden für die Einstellung ausgewählt, da ihre Entfernung entweder am wenigsten umstritten oder am nützlichsten ist. Am wenigsten umstritten sind beispielsweise 30 Jahre alte Multimediaformate wie das sunau-Audioformat, das Ende der 1980er Jahre auf SPARC- und NeXT-Workstations verwendet wurde. Das crypt-Modul hat grundlegende Fehler, die besser außerhalb der Standardbibliothek gelöst werden.

Dieses PEP bezeichnet auch einige Module, die nicht zur Entfernung vorgesehen sind. Einige Module wurden seit mehreren Veröffentlichungen eingestellt oder erscheinen auf den ersten Blick unnötig. Es ist jedoch vorteilhaft, die Module in der Standardbibliothek beizubehalten, hauptsächlich für Umgebungen, in denen die Installation eines Pakets von PyPI keine Option ist. Dies können Unternehmensumgebungen oder Klassenzimmer sein, in denen externer Code ohne rechtliche Genehmigung nicht zulässig ist.

  • Die Nutzung von FTP nimmt ab, aber einige Dateien werden immer noch über das FTP-Protokoll bereitgestellt oder Hoster bieten FTP zum Hochladen von Inhalten an. Daher wird ftplib beibehalten.
  • Die Module optparse und getopt sind weit verbreitet. Es handelt sich um ausgereifte Module mit sehr geringem Wartungsaufwand.
  • Laut David Beazley [5] ist das wave-Modul leicht für Kinder zu lehren und kann verrückte Geräusche erzeugen. Einen Computer Geräusche erzeugen zu lassen, ist eine mächtige und hochmotivierende Übung für einen neunjährigen angehenden Entwickler. Es ist eine lustige Batterie, die man behalten sollte.

Zeitplan für die Einstellung

3.11

Ab Python 3.11 beginnen eingestellte Module, DeprecationWarning auszugeben. Das geschätzte EOL (End of Life) von Python 3.10, der letzten Version ohne die Warnung, ist Oktober 2026.

3.12

Es sollte keine spezifische Änderung im Vergleich zu Python 3.11 geben. Dies ist die letzte Version von Python mit den eingestellten Modulen, mit einem geschätzten EOL im Oktober 2028.

3.13

Alle durch dieses PEP eingestellten Module werden aus dem main-Zweig des CPython-Repositorys entfernt und nicht mehr als Teil von Python verteilt.

Eingestellte Module

Die Module sind als Datenkodierung, Multimedia, Netzwerk, OS-Schnittstelle und diverse Module gruppiert. Die Mehrheit der Module sind für alte Datenformate oder alte APIs. Einige andere sind selten nützlich und haben bessere Ersetzungen auf PyPI, z. B. Pillow für die Bildverarbeitung oder NumPy-basierte Projekte zur Audioverarbeitung.

Tabelle 1: Vorgeschlagene Moduleinstellungen
Modul Eingestellt in Wird entfernt Hinzugefügt in Hat Wartungsperson? Ersatz
aifc 3.11 (3.0*) 3.13 1993 ja (inaktiv) -
asynchat 3.6 (3.0*) 3.12 1999 ja asyncio
asyncore 3.6 (3.0*) 3.12 1999 ja asyncio
audioop 3.11 (3.0*) 3.13 1992 ja -
cgi 3.11 (2.0**) 3.13 1995 nein -
cgitb 3.11 (2.0**) 3.13 1995 nein -
chunk 3.11 3.13 1999 nein -
crypt 3.11 3.13 1994 ja (inaktiv) legacycrypt, bcrypt, argon2-cffi, hashlib, passlib
imghdr 3.11 3.13 1992 nein filetype, puremagic, python-magic
mailcap 3.11 3.13 1995 nein -
msilib 3.11 3.13 2006 nein -
nntplib 3.11 3.13 1992 nein -
nis 3.11 (3.0*) 3.13 1992 nein -
ossaudiodev 3.11 3.13 2002 nein -
pipes 3.11 3.13 1992 nein subprocess
smtpd 3.4.7, 3.5.4 3.12 2001 ja aiosmtpd
sndhdr 3.11 3.13 1994 nein filetype, puremagic, python-magic
spwd 3.11 3.13 2005 nein python-pam
sunau 3.11 (3.0*) 3.13 1993 nein -
telnetlib 3.11 (3.0*) 3.13 1997 nein telnetlib3, Exscript
uu 3.11 3.13 1994 nein -
xdrlib 3.11 3.13 1992/1996 nein -

Einige Moduleinstellungen, die von PEP 3108 für 3.0 und PEP 206 für 2.0 vorgeschlagen wurden. Die Spalte „Hinzugefügt in“ zeigt an, wann ein Modul ursprünglich entwickelt und zur Standardbibliothek hinzugefügt wurde. Die Spalte „Hat Wartungsperson?“ bezieht sich auf den Expertenindex, eine Liste von Domänenexperten und Wartungspersonen im DevGuide.

Datenkodierungsmodule

uu und die uu-Kodierung

Das Modul uu bietet das uuencode-Format, eine alte binäre Kodierungsformat für E-Mails aus den 1980er Jahren. Das uu-Format wurde durch MIME ersetzt. Der uu-Codec wird vom Modul binascii bereitgestellt. Es gibt auch encodings/uu_codec.py, das ein Codec für die gleiche Kodierung ist; es sollte ebenfalls eingestellt werden.

xdrlib

Das Modul xdrlib unterstützt den Sun External Data Representation Standard. XDR ist ein altes binäres Serialisierungsformat aus dem Jahr 1987. Heutzutage wird es außerhalb spezialisierter Domänen wie NFS selten verwendet.

Multimedia-Module

aifc

Das Modul aifc bietet Unterstützung für das Lesen und Schreiben von AIFF- und AIFF-C-Dateien. Das Audio Interchange File Format ist ein altes Audioformat aus dem Jahr 1988, das auf Amiga IFF basiert. Es wurde am häufigsten auf dem Apple Macintosh verwendet. Heutzutage verwenden nur wenige spezialisierte Anwendungen AIFF.

Ein Benutzer hat [6] offengelegt, dass die Postproduktionsfilmindustrie das AIFC-Dateiformat intensiv nutzt. Die Verwendung des Moduls aifc in Closed-Source- und internen Software war vor der ersten Veröffentlichung dieses PEP unbekannt. Dies könnte ein überzeugendes Argument sein, das Modul aifc in der Standardbibliothek zu belassen. Das Dateiformat ist stabil und das Modul erfordert wenig Wartung. Die strategischen Vorteile für Python könnten die Belastung überwiegen.

audioop

Das Modul audioop enthält Hilfsfunktionen zur Bearbeitung von rohen Audiodaten und adaptiven differenziellen Pulscodemodulations-Audiodaten. Das Modul ist in C ohne zusätzliche Abhängigkeiten implementiert. Die Module aifc, sunau und wave hängen für einige Operationen von audioop ab.

Die Byte-Swapping-Operation im Modul wave kann mit wenig zusätzlichem Aufwand ersetzt werden. Falls aifc ebenfalls nicht eingestellt wird, wird eine reduzierte Version des Moduls audioop in ein privates Implementierungsdetail umgewandelt, z. B. _audioop mit byteswap, alaw2lin, ulaw2lin, lin2alaw, lin2ulaw und lin2adpcm.

chunk

Das Modul chunk bietet Unterstützung für das Lesen und Schreiben des Electronic Arts' Interchange File Format. IFF ist ein altes Audio-Dateiformat, das ursprünglich für Commodore und Amiga eingeführt wurde. Das Format ist nicht mehr relevant.

imghdr

Das Modul imghdr ist ein einfaches Werkzeug, um das Bilddatei-Format anhand der ersten 32 Bytes einer Datei oder eines Puffers zu erraten. Es unterstützt nur eine begrenzte Anzahl von Formaten und gibt weder Auflösung noch Farbtiefe zurück.

ossaudiodev

Das Modul ossaudiodev bietet Unterstützung für das Open Sound System, eine Schnittstelle zu Geräten für Soundwiedergabe und -aufnahme. OSS war ursprünglich Freie Software, aber später wurde die Unterstützung für neuere Soundgeräte und Verbesserungen proprietär. Die Linux-Gemeinschaft hat OSS zugunsten von ALSA aufgegeben [1]. Einige Betriebssysteme wie OpenBSD und NetBSD bieten eine unvollständige [2] Emulation von OSS.

Nach meinem besten Wissen ist FreeBSD das einzige weit verbreitete Betriebssystem, das heute Open Sound System verwendet. ossaudiodev hat seit 2003 keine Verbesserungen oder neuen Funktionen mehr erhalten. Alle Commits seit 2003 sind projektweite Code-Bereinigungen und einige wenige Fehlerkorrekturen. Es wäre sowohl für die FreeBSD-Gemeinschaft als auch für die Kernentwicklung von Vorteil, wenn das Modul von Leuten gewartet und verteilt würde, die sich dafür interessieren und es nutzen.

Die Standardbibliothek enthielt früher mehr audiobezogene Module. Die anderen Audio-Geräteschnittstellen (audiodev, linuxaudiodev, sunaudiodev) wurden 2007 im Rahmen der Standardbibliotheks-Neuorganisation von PEP 3108 entfernt.

sndhdr

Das Modul sndhdr ähnelt dem Modul imghdr, aber für Audioformate. Es errät das Dateiformat, die Kanäle, die Abtastrate und die Sample-Breiten anhand der ersten 512 Bytes einer Datei oder eines Puffers. Das Modul unterstützt nur AU, AIFF, HCOM, VOC, WAV und andere uralte Formate.

sunau

Das Modul sunau bietet Unterstützung für das Sun AU-Audioformat. Es ist ein weiteres altes, obsoletes Dateiformat.

Netzwerkmodule

asynchat

Das Modul asynchat basiert auf asyncore und ist seit Python 3.6 eingestellt.

asyncore

Das Modul asyncore war das erste Modul für asynchrone Socket-Dienst-Clients und -Server. Es wurde durch asyncio ersetzt und ist seit Python 3.6 eingestellt.

Das Modul asyncore wird auch in den Standardbibliotheks-Tests verwendet. Die Tests für ftplib, logging, smptd, smtplib und ssl basieren teilweise auf asyncore. Diese Tests müssen aktualisiert werden, um asyncio oder Threading zu verwenden.

cgi

Das Modul cgi ist ein Hilfsmodul für Common Gateway Interface (CGI)-Skripte. CGI gilt als ineffizient, da jede eingehende Anfrage in einem neuen Prozess behandelt wird. PEP 206 betrachtet das Modul als

„[...] schlecht konzipiert und sind jetzt kaum noch zu reparieren (cgi) [...]“

Ersatz für die verschiedenen Teile von cgi, die nicht direkt mit der Ausführung von Code zusammenhängen, sind

  • parse mit urllib.parse.parse_qs (parse ist nur ein Wrapper)
  • parse_header mit email.message.Message (siehe Beispiel unten)
  • parse_multipart mit email.message.Message (gleiche MIME-RFCs)
  • FieldStorage/MiniFieldStorage hat keinen direkten Ersatz, kann aber typischerweise durch Verwendung von multipart (für POST- und PUT-Anfragen) oder urllib.parse.parse_qsl (für GET- und HEAD-Anfragen ersetzt werden.
  • valid_boundary (undokumentiert) mit re.compile("^[ -~]{0,200}[!-~]$")

Als explizites Beispiel, wie nah parse_header und email.message.Message sind

>>> from cgi import parse_header
>>> from email.message import Message
>>> parse_header(h)
('application/json', {'charset': 'utf8'})
>>> m = Message()
>>> m['content-type'] = h
>>> m.get_params()
[('application/json', ''), ('charset', 'utf8')]
>>> m.get_param('charset')
'utf8'

cgitb

Das Modul cgitb ist ein Helfer für das Modul cgi für konfigurierbare Tracebacks.

Das Modul cgitb wird von keinem großen Python-Webframework (Django, Pyramid, Plone, Flask, CherryPy oder Bottle) verwendet. Nur Paste verwendet es in einer optionalen Debugging-Middleware.

smtpd

Das Modul smtpd bietet eine einfache Implementierung eines SMTP-Mailservers. Die Moduldokumentation kennzeichnet das Modul als eingestellt und empfiehlt aiosmtpd stattdessen. Die Einstellungsmeldung wurde in den Versionen 3.4.7, 3.5.4 und 3.6.1 hinzugefügt.

nntplib

Das Modul nntplib implementiert die Client-Seite des Network News Transfer Protocol (NNTP). News-Gruppen waren einst eine dominante Plattform für Online-Diskussionen. In den letzten zwei Jahrzehnten wurden News langsam, aber stetig durch Mailinglisten und webbasierte Diskussionsplattformen ersetzt. Twisted plant ebenfalls die Einstellung der NNTP-Unterstützung, und pynntp hat seit 2014 keine Aktivität mehr verzeichnet. Dies ist ein guter Indikator dafür, dass das öffentliche Interesse an NNTP-Unterstützung abnimmt.

Die Tests von nntplib waren in der Vergangenheit Ursache für zusätzliche Arbeit. Python enthält nur die Client-Seite von NNTP, daher verbinden sich die Tests mit externen News-Servern. Die Server sind manchmal nicht verfügbar, zu langsam oder funktionieren über IPv6 nicht richtig. Die Situation führt zu instabilen Testergebnissen auf Buildbots.

telnetlib

Das Modul telnetlib stellt eine Telnet-Klasse zur Verfügung, die das Telnet-Protokoll implementiert.

Betriebssystem-Schnittstelle

crypt

Das Modul crypt implementiert das Hashing von Passwörtern basierend auf der Funktion crypt(3) von libcrypt oder libxcrypt auf Unix-ähnlichen Plattformen. Die Algorithmen sind größtenteils alt, von schlechter Qualität und unsicher. Benutzer werden von ihrer Verwendung abgeraten.

  • Das Modul ist unter Windows nicht verfügbar. Plattformübergreifende Anwendungen benötigen ohnehin eine alternative Implementierung.
  • Nur DES-Verschlüsselung ist garantiert verfügbar. DES hat einen extrem begrenzten Schlüsselraum von 2**56.
  • MD5, gesalzenes SHA256, gesalzenes SHA512 und Blowfish sind optionale Erweiterungen. SSHA256 und SSHA512 sind glibc-Erweiterungen. Blowfish (bcrypt) ist der einzige Algorithmus, der noch sicher ist. Er ist jedoch in glibc enthalten und daher unter Linux nicht allgemein verfügbar.
  • Je nach Plattform ist das Modul crypt nicht threadsicher. Nur Implementierungen mit crypt_r(3) sind threadsicher.
  • Das Modul war nie nützlich für die Interaktion mit Systembenutzer- und Passwortdatenbanken. Auf BSD, macOS und Linux müssen alle Benutzerauthentifizierungs- und Passwortänderungsoperationen über PAM (Pluggable Authentication Module) laufen; siehe die Einstellung von spwd.

nis

Das Modul nis bietet NIS/YP-Unterstützung. Network Information Service / Yellow Pages ist ein altes und eingestelltes Verzeichnisdienstprotokoll, das von Sun Microsystems entwickelt wurde. Sein konzipierter Nachfolger NIS+ aus dem Jahr 1992 hat sich nie durchgesetzt. Seit langem gelten der Name Service Switch von libc, LDAP und Kerberos/GSSAPI als leistungsfähigere und sicherere Alternative zu NIS.

spwd

Das Modul spwd bietet direkten Zugriff auf die Unix-Shadow-Passwortdatenbank über nicht standardmäßige APIs.

Im Allgemeinen ist es eine schlechte Idee, spwd zu verwenden. Es umgeht System-Sicherheitsrichtlinien, verwendet nicht den PAM-Stack und ist nur mit lokalen Benutzerkonten kompatibel, da es NSS ignoriert. Die Verwendung des Moduls spwd zur Zugriffskontrolle muss als Sicherheitslücke betrachtet werden, da es die Zugriffskontrolle von PAM umgeht.

Darüber hinaus verwendet das Modul spwd die shadow(3) APIs. Funktionen wie getspnam(3) greifen direkt auf die Datei /etc/shadow zu. Dies ist gefährlich und für eingeschränkte Dienste auf Systemen mit einer Sicherheits-Engine wie SELinux oder AppArmor sogar verboten.

Diverse Module

mailcap

Das Paket mailcap liest Mail-Capability-Dateien, um beim Umgang mit Dateianhängen in E-Mails zu helfen. In den meisten modernen Betriebssystemen kümmert sich der E-Mail-Client selbst um die Reaktion auf Dateianhänge. Betriebssysteme haben auch eigene Möglichkeiten, die Handhabung von Dateien anhand ihrer Dateinamen-Erweiterung zu registrieren. Schließlich hat das Modul CVE-2015-20107 gegen sich, während es keinen Wartungsperson gibt, der bei der Behebung helfen könnte.

msilib

Das Paket msilib ist ein reines Windows-Paket. Es unterstützt die Erstellung von Microsoft Installern (MSI). Das Paket stellt auch zusätzliche APIs zur Erstellung von Cabinet-Dateien (CAB) bereit. Das Modul wird verwendet, um distutils die Erstellung von MSI-Installern mit dem Befehl bdist_msi zu erleichtern. Früher wurde es auch zur Erstellung des offiziellen Windows-Installers von CPython verwendet.

Microsoft bewegt sich langsam weg von MSI zugunsten von Windows 10 Apps (AppX) als neues Bereitstellungsmodell [3].

pipes

Das Modul pipes bietet Hilfsmittel zum Verketten der Eingabe eines Befehls mit der Ausgabe eines anderen Befehls. Das Modul basiert auf os.popen. Benutzern wird empfohlen, stattdessen das Modul subprocess zu verwenden.

Module, die beibehalten werden

Einige Module wurden ursprünglich zur Einstellung vorgeschlagen, sind aber in diesem PEP nicht mehr als solche aufgeführt.

Tabelle 2: Zurückgezogene Einstellungen
Modul Eingestellt in Ersatz
colorsys - colormath, colour, colorspacious, Pillow
fileinput - argparse
getopt - argparse, optparse
optparse 3.2 argparse
wave -

colorsys

Das Modul colorsys definiert Farbumwandlungsfunktionen zwischen RGB-, YIQ-, HSL- und HSV-Koordinatensystemen.

Walter Dörwald, Petr Viktorin und andere baten darum, colorsys beizubehalten. Das Modul ist nützlich für die Umwandlung von CSS-Farben zwischen Koordinatensystemen. Die Implementierung ist einfach, ausgereift und belastet die Kernentwicklung nicht mit Wartungsaufwand.

Die PyPI-Pakete colormath, colour und colorspacious bieten mehr und fortschrittlichere Funktionen. Die Pillow-Bibliothek eignet sich besser für die Transformation von Bildern zwischen Farbsystemen.

fileinput

Das Modul fileinput implementiert Hilfsmittel zur Iteration über eine Liste von Dateien aus sys.argv. Das Modul stammt aus der Zeit vor den Modulen optparse und argparse. Die gleiche Funktionalität kann mit dem Modul argparse implementiert werden.

Mehrere Kernentwickler äußerten ihr Interesse daran, das Modul in der Standardbibliothek zu belassen, da es für schnelle Skripte nützlich ist.

getopt

Das Modul getopt ahmt den C-Optionen-Parser getopt() nach.

Obwohl Benutzern empfohlen wird, stattdessen argparse zu verwenden, ist das Modul getopt immer noch weit verbreitet. Das Modul ist klein, einfach und praktisch für C-Entwickler, um einfache Python-Skripte zu schreiben.

optparse

Das Modul optparse ist der Vorgänger des Moduls argparse.

Obwohl es seit vielen Jahren als veraltet gilt, wird es immer noch zu weit verwendet, um es zu entfernen.

wave

Das Modul wave bietet Unterstützung für das WAV-Soundformat.

Das Modul ist nicht veraltet, da das WAV-Format heutzutage immer noch relevant ist. Das Modul wave wird auch in der Ausbildung verwendet, z. B. um Kindern zu zeigen, wie man mit einem Computer Geräusche macht.

Das Modul verwendet eine einfache Funktion aus dem Modul audioop, um Byte-Swapping zwischen Little- und Big-Endian-Formaten durchzuführen. Bevor die Unterstützung für 24-Bit-WAV hinzugefügt wurde, wurde das Byte-Swapping mit dem Modul array implementiert. Um die Abhängigkeit von wave von audioop zu entfernen, könnte die Byte-Swapping-Funktion entweder in ein anderes Modul (z. B. operator) verschoben oder das Modul array könnte Unterstützung für 24-Bit-(3-Byte)-Arrays erhalten.

Diskussionen

  • Elana Hashman und Alyssa Coghlan schlugen vor, das Modul getopt beizubehalten.
  • Berker Peksag schlug vor, msilib als veraltet zu erklären und zu entfernen.
  • Brett Cannon empfahl, aktive Veraltungswarnungen und die Entfernung von Modulen wie imp bis Python 3.10 zu verschieben. Version 3.8 wird kurz vor dem Ende der Lebensdauer von Python 2 veröffentlicht. Eine Verschiebung reduzierte den Aufwand für Benutzer, die von Python 2 auf 3.8 migrieren.
  • An einem Punkt wurde distutils im selben Satz wie dieses PEP erwähnt. Um lange Diskussionen und Verzögerungen des PEP zu vermeiden, entschied ich mich gegen die Behandlung von distutils. Die Veraltung des distutils-Pakets wird von einem anderen PEP behandelt.
  • Mehrere Personen (Gregory P. Smith, David Beazley, Alyssa Coghlan, ...) überzeugten mich, das Modul wave beizubehalten. [4]
  • Gregory P. Smith schlug vor, nntplib als veraltet zu kennzeichnen. [4]
  • Andrew Svetlov erwähnte, dass das Modul socketserver fragwürdig sei. Es wird jedoch verwendet, um http.server und xmlrpc.server zu implementieren. Die Standardbibliothek hat noch keinen Ersatz für die Server.

Abgelehnte Ideen

Erstellung/Pflege eines separaten Repos für die eingestellten Module

Es wurde zuvor vorgeschlagen, ein separates Repository zu erstellen, das die veralteten Module enthält, die für die Installation verpackt sind. Einer der PEP-Autoren ging sogar so weit, ein Demo-Repository zu erstellen. Letztendlich wurde jedoch beschlossen, dass der zusätzliche Aufwand, ein solches Repo zu erstellen und offiziell zu pflegen, nicht gerechtfertigt war, da der Quellcode im CPython-Repository weiterhin verfügbar sein wird, damit Leute ihn nach Bedarf einbinden können. Ähnliche Arbeiten wurden auch nicht durchgeführt, als frühere Module veraltet und entfernt wurden, und es war anscheinend keine übermäßige Belastung für die Community.

Aktualisierungsverlauf

Update 1

  • Modul parser als veraltet kennzeichnen
  • Modul fileinput beibehalten
  • Ausführen, warum crypt und spwd gefährlich und schlecht sind
  • Abschnitte für die Module cgitb, colorsys, nntplib und smtpd verbessern
  • Die Abschnitte für colorsys, crypt, imghdr, sndhdr und spwd listen nun geeignete Ersetzungen auf
  • Erwähnen, dass socketserver für http.server und xmlrpc.server beibehalten wird
  • Der Abschnitt zur zukünftigen Wartung besagt nun, dass die veralteten Module von Mitgliedern der Python-Community übernommen werden können

Update 2

  • Modul colorsys beibehalten
  • Experten hinzufügen
  • Diskussionen auf discuss.python.org umleiten
  • telnetlib als veraltet kennzeichnen
  • Die compat32-Richtlinie des Pakets email als veraltet kennzeichnen
  • Erstellungsjahr zur Übersichtstabelle hinzufügen
  • Hinweis auf PEP 206 und PEP 3108
  • Abschnitte für aifc, audioop, cgi und wave aktualisieren.

Update 3

  • Die Legacy-API-Module für E-Mail beibehalten. Interne Veraltungen werden separat behandelt.

Update 4

  • Brett als Koautor hinzufügen.
  • PEP für Python 3.11 neu ausrichten.
  • Beispiele, wie die relevanten Teile von cgi ersetzt werden können (danke Martijn Pieters).

Referenzen


Quelle: https://github.com/python/peps/blob/main/peps/pep-0594.rst

Zuletzt geändert: 2024-05-25 13:48:58 GMT