Welche Module sollten durch __preview__ laufen

Wir erwarten, dass die meisten für die Aufnahme in die Python-Standardbibliothek vorgeschlagenen Module eine Minor-Version in __preview__ durchlaufen werden. Es kann jedoch einige Ausnahmen geben, z. B. Module, die eine vordefinierte API verwenden (z. B. lzma, das im Allgemeinen der API des bestehenden bz2-Moduls folgt) oder Module mit einer API, die in der Python-Entwickler-Community weite Akzeptanz findet.

In jedem Fall müssen Module, die zur Aufnahme in die Standardbibliothek vorgeschlagen werden, sei es über __preview__ oder direkt, die von PEP 2 festgelegten Annahmekriterien erfüllen.

Es ist wichtig zu betonen, dass das Ziel dieses Vorschlags nicht darin besteht, den Prozess der Aufnahme neuer Module in die Standardbibliothek zu erschweren. Im Gegenteil, er versucht, ein Mittel bereitzustellen, um *mehr* nützliche Bibliotheken aufzunehmen. Module, die offensichtliche Kandidaten für die Aufnahme sind, können wie bisher aufgenommen werden. Module, die aufgrund von Unsicherheiten bezüglich der API lange Zeit ins Stocken geraten könnten, haben nun ein Mittel, um trotzdem mit Python vertrieben zu werden, durch eine Inkubationsphase im __preview__-Paket.

Kriterien für die „Beförderung“

Grundsätzlich sollten die meisten Module im __preview__-Paket schließlich in die stabile Standardbibliothek überführt werden. Einige Gründe, die dagegen sprechen:

• Das Modul könnte sich als instabil oder fragil erweisen, ohne ausreichende Entwicklerunterstützung zur Wartung.
• Ein wesentlich besseres alternatives Modul könnte während der Vorschauversion gefunden werden.

Im Wesentlichen wird die Entscheidung von den Kernentwicklern von Fall zu Fall getroffen. Der Punkt, der hier betont werden soll, ist, dass die Aufnahme eines Moduls in das __preview__-Paket in einer bestimmten Version nicht garantiert, dass es auch in der nächsten Version Teil von Python bleibt.

Beispiel

Angenommen, das example-Modul ist ein Kandidat für die Aufnahme in die Standardbibliothek, aber einige Python-Entwickler sind nicht davon überzeugt, dass es die beste API für das Problem bietet, das es lösen soll. Das Modul kann dann in Version 3.X in das __preview__-Paket aufgenommen werden und ist importierbar über

from __preview__ import example

Unter der Annahme, dass das Modul dann in Version 3.X+1 in die Standardbibliothek proper befördert wird, wird es an einen festen Platz in der Bibliothek verschoben.

import example

Und der Import aus __preview__ funktioniert dann nicht mehr.

Vorteile für das Kernentwicklungsteam

Derzeit sind die Kernentwickler sehr zurückhaltend, neue Schnittstellen zur Standardbibliothek hinzuzufügen. Das liegt daran, dass API-Designfehler, sobald sie in einer Veröffentlichung veröffentlicht sind, aufgrund von Kompatibilitätsbedenken festgeschrieben werden.

Indem wir alle wichtigen API-Ergänzungen durch einen Vorschau-Mechanismus für eine vollständige Version laufen lassen, erhalten wir einen vollständigen Release-Zyklus an Community-Feedback, bevor wir die APIs mit unserer üblichen Abwärtskompatibilitätsgarantie festschreiben.

Wir können auch anfangen, Vorschau-Module frühzeitig mit dem Rest der Standardbibliothek zu integrieren, solange wir den Packagern klar machen, dass die Vorschau-Module nicht als optional betrachtet werden sollten. Der einzige Unterschied zwischen Vorschau-APIs und dem Rest der Standardbibliothek besteht darin, dass Vorschau-APIs ausdrücklich von den üblichen Abwärtskompatibilitätsgarantien ausgenommen sind.

Im Wesentlichen soll das __preview__-Paket das Risiko verringern, kleinere API-Designfehler über längere Zeiträume festzuschreiben. Derzeit kann diese Sorge neue Ergänzungen blockieren, selbst wenn der Konsens des Kernentwicklungsteams darin besteht, dass eine bestimmte Ergänzung grundsätzlich eine gute Idee ist.

Vorteile für Endbenutzer

Für zukünftige Endbenutzer liegt der größte Vorteil in einer besseren „Out-of-the-box“-Erfahrung – anstatt zu hören: „Oh, die Standardbibliothekstools für Aufgabe X sind schrecklich, lade dir diese Drittanbieterbibliothek stattdessen herunter“, sind diese überlegenen Tools wahrscheinlich nur einen Import entfernt.

Für Umgebungen, in denen Entwickler eine sorgfältige Prüfung ihrer Upstream-Abhängigkeiten durchführen müssen (was die Kosteneffizienz von PyPI-Material erheblich beeinträchtigt oder sogar gänzlich ausschließt), liegt der Hauptvorteil darin, dass alles im __preview__-Paket klar unter der Ägide von python-dev steht, zumindest aus folgenden Perspektiven:

• Lizenzierung: Weiterverteilt von der PSF unter einer Contributor Licensing Agreement.
• Dokumentation: Die Dokumentation des Moduls wird über die Standard-Python-Dokumentationswerkzeuge veröffentlicht und organisiert (d.h. ReST-Quelle, Ausgabe generiert mit Sphinx und veröffentlicht auf https://docs.pythonlang.de).
• Testen: Die Test-Suiten des Moduls werden auf der Python.org Buildbot-Flotte ausgeführt und die Ergebnisse über https://pythonlang.de/dev/buildbot veröffentlicht.
• Problemverwaltung: Fehler und Funktionsanfragen werden auf http://bugs.python.org bearbeitet.
• Quellcodeverwaltung: Das Hauptrepository für die Software wird auf http://hg.python.org veröffentlicht.

Verwendung von __future__

Python hat bereits einen „vorausschauenden“ Namensraum in Form des __future__-Moduls, daher ist es vernünftig zu fragen, warum dieser nicht für diesen neuen Zweck wiederverwendet werden kann.

Es gibt zwei Gründe, warum dies nicht angemessen ist:

1. Das __future__-Modul ist tatsächlich mit einer separaten Compiler-Direktiven-Funktion verbunden, die tatsächlich die Art und Weise ändern kann, wie der Python-Interpreter ein Modul kompiliert. Das wollen wir für das Vorschau-Paket nicht – wir wollen nur ein gewöhnliches Python-Paket.

2. Das __future__-Modul wird mit einer ausdrücklichen Zusage geliefert, dass Namen auf Dauer beibehalten werden, lange nachdem die zugehörigen Funktionen zum Standardverhalten des Compilers geworden sind. Auch hier ist das genau das Gegenteil von dem, was für das Vorschau-Paket beabsichtigt ist – es ist fast sicher, dass alle Namen, die dem Vorschau-Paket hinzugefügt werden, irgendwann entfernt werden, höchstwahrscheinlich aufgrund ihrer Verschiebung an einen festen Platz in der Standardbibliothek, aber auch potenziell aufgrund ihrer Rückstufung zum Drittanbieter-Paket (wenn das Community-Feedback darauf hindeutet, dass die vorgeschlagene Ergänzung unwiederbringlich fehlerhaft ist).

Versionierung des Pakets

Ein vorgeschlagener Alternativvorschlag [1] war, eine explizite Versionierung zum __preview__-Paket hinzuzufügen, z. B. __preview34__. Wir denken, dass es besser ist, einfach zu definieren, dass ein Modul, das in Python 3.X in __preview__ enthalten ist, entweder in Python 3.X+1 in den normalen Standardbibliothek-Namensraum „befördert“ wird oder ganz aus dem Python-Quellbaum verschwindet. Die Versionierung des __preview__-Pakets kompliziert den Prozess und passt nicht gut zum Hauptziel dieses Vorschlags.

Verwendung eines Paketnamens ohne führende und abschließende Unterstriche

Es wurde vorgeschlagen [1], einen Paketnamen wie preview oder exp anstelle von __preview__ zu verwenden. Dies wurde in der Diskussion abgelehnt, da ein „Dunder“-Paketname (d. h. ein Name *mit* führenden und abschließenden doppelten Unterstrichen) in Python eine besondere Bedeutung hat. Außerdem würde ein Nicht-Dunder-Name normale Abwärtskompatibilitätsgarantien der Standardbibliothek suggerieren, was nicht die Absicht des __preview__-Pakets ist.

Beibehaltung der Pickle-Kompatibilität

Eine über pickle serialisierte Klasseninstanz, die auf einem Modul in __preview__ in Version 3.X basiert, wird in Version 3.X+1 nicht mehr deserialisierbar sein, wo das Modul nicht mehr in __preview__ enthalten ist. Spezieller Code könnte hinzugefügt werden, um dies zu ermöglichen, aber das widerspricht der Absicht dieses Vorschlags, da es Abwärtskompatibilität impliziert. Daher schlägt dieses PEP keine Beibehaltung der pickle-Kompatibilität vor.