Einführung eines compression-Pakets

Sowohl die Importnamen zstd als auch zstandard werden von Projekten auf PyPI beansprucht. Um Benutzer bestehender Bindungen nicht zu beeinträchtigen, schlägt dieser PEP die Einführung eines neuen Namensraums für Komprimierungsbibliotheken, compression, vor. Dieser Name ist auf PyPI bereits für die Verwendung in der Standardbibliothek reserviert. Das neue Zstandard-Modul wird compression.zstd heißen. Andere Komprimierungsmodule werden im neuen compression-Paket neu exportiert.

Die Bereitstellung eines gemeinsamen Namensraums für Komprimierungsmodule hat mehrere Vorteile. Erstens reduziert es die Verwirrung der Benutzer darüber, wo sie Komprimierungsmodule finden können. Zweitens könnte das Top-Level-Modul compression Informationen darüber liefern, welche Komprimierungsformate verfügbar sind, ähnlich wie bei hashlib's algorithms_available. Wenn PEP 775 akzeptiert wird, könnte auch ein compression.algorithms_guaranteed bereitgestellt werden, das zlib auflistet. Schließlich verhindert ein compression-Namensraum zukünftige Probleme beim Zusammenführen anderer Komprimierungsformate in die Standardbibliothek. Neue Komprimierungsformate werden wahrscheinlich zuerst auf PyPI veröffentlicht, bevor sie in CPython integriert werden. Daher wird jeder neue Importname für ein Komprimierungsformat wahrscheinlich bereits beansprucht sein, wenn ein Modul für die Aufnahme in CPython in Betracht gezogen wird. Das Platzieren von Komprimierungsmodulen unter einem Paketpräfix verhindert Probleme mit potenziellen zukünftigen Namenskonflikten.

Code, der mit verschiedenen Python-Versionen kompatibel bleiben soll, kann das folgende Muster verwenden, um die Kompatibilität sicherzustellen

try:
    from compression.lzma import LZMAFile
except ImportError:
    from lzma import LZMAFile

Dies verwendet den neueren Importnamen, wenn verfügbar, und greift andernfalls auf den alten Namen zurück.

Implementierung basierend auf pyzstd

Die Implementierung für diesen PEP basiert auf dem pyzstd-Projekt. Dieses Projekt wurde ausgewählt, da der Code ursprünglich dafür geschrieben wurde, von Ma Lin in CPython eingebracht zu werden, der auch die heutige Implementierung des Ausgabepuffers in der Standardbibliothek schrieb. Das Projekt wurde inzwischen von Rogdham übernommen und auf PyPI veröffentlicht. Die APIs in pyzstd ähneln den APIs für andere Komprimierungsmodule in der Standardbibliothek wie bz2 und lzma.

Mindestens unterstützte Zstandard-Version

Die minimal unterstützte Zstandard-Version wurde als v1.4.5 gewählt, die im Mai 2020 veröffentlicht wurde. Diese Version wurde als Minimum gewählt, nachdem die verfügbaren Zstandard-Versionen in einer Reihe von Linux-Distribution-Paket-Repositories, einschließlich LTS-Versionen, geprüft wurden. Diese Versionswahl ist eher konservativ, um die Kompatibilität mit bestehenden LTS-Linux-Distributionen zu maximieren, aber eine neuere Zstandard-Version könnte wahrscheinlich gewählt werden, da neuere Python-Releases im Allgemeinen als Teil neuerer Distributions-Releases verpackt werden.

Der compression-Namensraum

Ein neuer Namensraum für Komprimierungsmodule wird namens compression eingeführt. Das Top-Level-Modul für dieses Paket wird zunächst leer sein, aber eine Standard-API für die Interaktion mit Komprimierungsroutinen könnte zukünftig zum Top-Level hinzugefügt werden.

Das Modul compression.zstd

Ein neues Modul, compression.zstd, wird mit Zstandard-Komprimierungs-APIs eingeführt, die mit anderen Komprimierungsmodulen in der Standardbibliothek übereinstimmen, nämlich:

• compress() / decompress() – APIs für einmalige Komprimierung oder Dekomprimierung
• ZstdFile / open() – APIs für die Interaktion mit Streams und dateiähnlichen Objekten
• ZstdCompressor / ZstdDecompressor – APIs für inkrementelle Komprimierung oder Dekomprimierung

Es wird auch einige Zstandard-spezifische Funktionalität enthalten:

• ZstdDict / train_dict() / finalize_dict() – APIs für die Interaktion mit Zstandard-Wörterbüchern, die für die Komprimierung vieler kleiner Datenblöcke mit ähnlichen Daten nützlich sind

Optionale Abhängigkeit libzstd

Die libzstd-Bibliothek wird zu einer optionalen Abhängigkeit von CPython. Wenn die Bibliothek nicht verfügbar ist, ist das Modul compression.zstd nicht verfügbar. Dies wird unter Unix-Plattformen automatisch als Teil der normalen Build-Umgebungsprüfung gehandhabt.

Unter Windows wird libzstd zu den Quellabhängigkeiten hinzugefügt, die zum Erstellen von Bibliotheken verwendet werden, von denen CPython für Windows abhängt.

Andere Komprimierungsmodule

Neue Importnamen compression.lzma, compression.bz2, compression.gzip und compression.zlib werden in Python 3.14 eingeführt und exportieren den Inhalt der bestehenden Module lzma, bz2, gzip bzw. zlib. Die compression-Untermodule werden zukünftig die kanonischen Importnamen sein. Die Verwendung der neuen Komprimierungsnamen wird in der Python-Dokumentation gegenüber den ursprünglichen Top-Level-Modulnamen gefördert, wenn die Mindestanforderungen an die unterstützte Python-Version dies zulassen.

Das Modul _compression wird, da es als privat markiert ist, sofort in compression._common._streams umbenannt. Der neue Name wurde gewählt, da die aktuellen Inhalte des Moduls I/O-bezogene Helfer für Stream-APIs (z.B. LZMAFile) in Standardbibliotheks-Komprimierungsmodulen sind.

Benennen Sie das Modul zstdlib und erstellen Sie keinen neuen compression-Namensraum

Eine Option anstelle der Erstellung eines neuen compression-Namensraums wäre die Suche nach einem anderen Namen, wie z.B. zstdlib, als Importnamen. Mehrere andere Namen wie zst, libzstd und zstdcomp wurden ebenfalls vorgeschlagen. In der Diskussion wurden die Namen als entweder zu fehleranfällig oder unintuitiv befunden. Darüber hinaus ist das Problem bestehender Importnamen wahrscheinlich für zukünftige Komprimierungsformate, die der Standardbibliothek hinzugefügt werden, weiterhin relevant. LZ4, ein gängiges Hochgeschwindigkeits-Komprimierungsformat, hat ein Paket auf PyPI, lz4, mit dem Importnamen lz4. Anstatt dieses Problem für jedes Komprimierungsformat einzeln zu lösen, ist es besser, es ein für alle Mal durch die Verwendung des bereits beanspruchten compression-Namensraums zu lösen.

Führen Sie ein experimentelles _zstd-Paket in Python 3.14 ein

Da dieser PEP nahe am Beta-Cutoff für neue Features für Python 3.14 veröffentlicht wurde, war ein Vorschlag, das Paket als privates Modul _zstd zu benennen, damit Paketierungswerkzeuge es früher nutzen können, aber keinen Namen festzulegen. Dies würde mehr Zeit für die Diskussion des endgültigen Modulnamens während des Entwicklungsfensters für 3.15 ermöglichen. Die Einführung eines privaten Moduls war jedoch nicht beliebt. Die Erwartungen und der Vertrag für die externe Nutzung eines privaten Moduls in der Standardbibliothek sind unklar.

Führen Sie einen Standardbibliotheksnamensraum anstelle von compression ein

Eine Alternative zu einem compression-Namensraum wäre die Einführung eines std-Namensraums für die gesamte Standardbibliothek. Dies wurde jedoch als zu bedeutende Änderung für 3.14 angesehen, ohne vereinbarte Semantik, Migrationspfade oder einen Namen für das Paket. Darüber hinaus könnte ein zukünftiger PEP, der einen std-Namensraum einführt, immer definieren, dass die compression-Untermodule in den std-Namensraum abgeflacht werden.

Schließen Sie zipfile und tarfile in compression ein

Komprimierung wird oft mit Archivierungswerkzeugen verwendet, daher ist es attraktiv, sowohl zipfile als auch tarfile unter dem compression-Namensraum zu platzieren. Komprimierung kann jedoch auch außerhalb von Archivierungswerkzeugen verwendet werden. Zum Beispiel können Netzwerkanfragen mit Gzip komprimiert werden. Darüber hinaus enthalten Formate wie tar selbst keine Komprimierung, sondern verlassen sich auf externe Komprimierung. Daher schlägt dieser PEP nicht vor, zipfile oder tarfile unter compression zu verschieben.

Schließen Sie gzip nicht unter compression ein

Das GZip-Format RFC definiert ein Format, das mehrere Blöcke und Metadaten über seinen Inhalt enthalten kann. Auf diese Weise ähnelt GZip stark Archivformaten wie ZIP und tar. Trotzdem wird GZip in der Anwendung oft eher als Komprimierungsformat denn als Archivformat behandelt. Betrachtet man, wie verschiedene Sprachen GZip klassifizieren, so ist der vorherrschende Trend, es als Komprimierungsformat und nicht als Archivierungsformat zu klassifizieren.

Darüber hinaus konzentriert sich das gzip-Modul in Python hauptsächlich auf Inhalte mit einzelnen Blöcken und hat eine ähnliche API wie andere Komprimierungsmodule, was es gut für den compression-Namensraum geeignet macht.