Zu wenige Projekte beteiligen sich an der Python-Beta-Phase

Derzeit sind Python-Beta-Versionen vier Monate vor der finalen 3.x.0-Veröffentlichung verfügbar.

Während der Beta-Phase gemeldete Fehler können leicht behoben werden und eine Veröffentlichung blockieren, wenn sie schwerwiegend genug sind.

Inkompatible Änderungen werden während der Beta-Phase diskutiert: Verbesserung der Dokumentation, die erklärt, wie Code aktualisiert wird, oder Berücksichtigung der Rückgängigmachung dieser Änderungen.

Auch wenn immer mehr Projekte den Master-Branch von Python in ihrem CI testen, sind zu viele Projekte der Top-50-PyPI-Projekte erst Wochen oder sogar Monate nach der finalen Python-Veröffentlichung mit dem neuen Python kompatibel.

DeprecationWarning wird ignoriert

Python hat einen gut definierten Prozess zur Deprecation von Features. Eine DeprecationWarning muss mindestens eine Python-Veröffentlichung lang ausgegeben werden, bevor ein Feature entfernt werden kann.

In der Praxis werden DeprecationWarning-Warnungen in wichtigen Python-Projekten jahrelang ignoriert. Üblicherweise erklären Maintainer, dass es zu viele Warnungen gibt und sie diese daher einfach ignorieren. Außerdem ist DeprecationWarning standardmäßig stumm (außer im __main__ Modul: PEP 565).

Auch wenn immer mehr Projekte ihre Testsuite mit Warnungen als Fehler behandeln (-Werror), haben Python-Kernentwickler immer noch keine Ahnung, wie viele Projekte betroffen sind, wenn ein Feature entfernt wird.

Koordination erforderlich

Wenn Probleme und inkompatible Änderungen nach der finalen Python-Veröffentlichung entdeckt und diskutiert werden, ist die Behebung von Python wesentlich komplizierter und teurer. Sobald eine API Teil einer offiziellen finalen Veröffentlichung ist, sollte Python die Abwärtskompatibilität für die gesamte Lebensdauer der 3.x-Veröffentlichung gewährleisten. Einige Betriebssysteme können mit der fehlerhaften finalen Veröffentlichung ausgeliefert werden und es kann mehrere Monate dauern, bis sie aktualisiert werden.

Zu viele Projekte werden erst nach der finalen Python-Veröffentlichung auf das neue Python aktualisiert, was diese neue Python-Version bei der Veröffentlichung von Python für große Anwendungen kaum nutzbar macht.

Es wird vorgeschlagen, eine Python-Veröffentlichung zu blockieren, bis eine kompatible Version aller ausgewählten Projekte verfügbar ist.

Kürzere Python-Veröffentlichungsplanung

Die PEP 602: Jahreszyklus für Python-Veröffentlichungen und die PEP 605: Ein rollierender Feature-Release-Stream für CPython möchten Python öfter veröffentlichen, um neue Features schneller bereitzustellen.

Das Problem ist, dass jede 3.x Python-Veröffentlichung viele Projekte beeinträchtigt.

Koordinierte Python-Veröffentlichungen reduzieren die Anzahl betroffener Projekte und machen neue Python-Veröffentlichungen nutzbarer.

Verzögerung begrenzen

Wenn ein Build- oder Testproblem mit der nächsten Python-Version an ein Projekt gemeldet wird, haben Maintainer einen Monat Zeit zu antworten. Ohne Antwort kann das Projekt von der Liste der die Python-Veröffentlichung blockierenden Projekte ausgeschlossen werden.

Mehrere Projekte werden bereits auf dem Master-Branch von Python in einem CI getestet. Probleme können sehr früh in einer Python-Veröffentlichung erkannt werden, was genügend Zeit zur Behebung bieten sollte. Weitere CIs können für Projekte hinzugefügt werden, die noch nicht auf dem nächsten Python getestet werden.

Sobald Probleme mit ausgewählten Projekten bekannt sind, können Ausnahmen auf Fall-zu-Fall-Basis zwischen dem Python Release Manager und den beteiligten Projekt-Maintainern diskutiert werden. Nicht alle Probleme verdienen es, eine Python-Veröffentlichung zu blockieren.

Ausgewählte Projekte

Liste der Projekte, die eine Python-Veröffentlichung blockieren (gesamt: 27)

• Projekte (13)
  • aiohttp
  • cryptography
  • Cython
  • Django
  • numpy
  • pandas
  • pip
  • requests
  • scipy
  • Sphinx (wird zum Erstellen von Python benötigt)
  • sqlalchemy
  • pytest
  • tox
• Direkte und indirekte Abhängigkeiten (14)
  • certifi (wird von urllib3 benötigt)
  • cffi (wird von cryptography benötigt)
  • chardet (wird von Sphinx benötigt)
  • colorama (wird von pip benötigt)
  • docutils (wird von Sphinx benötigt)
  • idna (wird von Sphinx und requests benötigt)
  • jinja2 (wird von Sphinx benötigt)
  • MarkupSafe (wird von Sphinx benötigt)
  • psycopg2 (wird von Django benötigt)
  • pycparser (wird von cffi benötigt)
  • setuptools (wird von pip und vielen Python-Projekten benötigt)
  • six (wird von vielen Python-Projekten benötigt)
  • urllib3 (wird von requests benötigt)
  • wheel (wird von pip benötigt)

Wie Projekte ausgewählt werden

Projekte, die zum Erstellen von Python verwendet werden, sollten in der Liste sein, z. B. Sphinx.

Die beliebtesten Projekte werden aus den am häufigsten heruntergeladenen PyPI-Projekten ausgewählt.

Die meisten Projektabhängigkeiten sind ebenfalls in der Liste enthalten, da eine einzige inkompatible Abhängigkeit ein ganzes Projekt blockieren kann. Einige Abhängigkeiten sind ausgeschlossen, um die Listenlänge zu reduzieren.

Testabhängigkeiten wie pytest und tox sollten ebenfalls enthalten sein. Wenn ein Projekt nicht getestet werden kann, kann auch keine neue Version ausgeliefert werden.

Die Liste sollte lang genug sein, um eine gute Vorstellung von den Kosten der Portierung eines Projekts auf das nächste Python zu bekommen, aber kurz genug, um eine Python-Veröffentlichung nicht zu lange zu blockieren.

Offensichtlich werden Projekte, die nicht Teil der Liste sind, ebenfalls ermutigt, Probleme mit dem nächsten Python zu melden und einen CI mit der nächsten Python-Version auszuführen.

Beispiele

Es gibt verschiedene Arten von inkompatiblen Änderungen

• Änderung im Python-Build. Zum Beispiel hat Python 3.8 'm' (was für pymalloc steht) aus sys.abiflags entfernt, was Python-Anbieter wie Linux-Distributionen betrifft.
• Änderung im C-Extensions-Build. Zum Beispiel verknüpft Python 3.8 C-Extensions nicht mehr mit libpython, und Python 3.7 hat den Alias os.errno für das Modul errno entfernt.
• Entfernte Funktion. Zum Beispiel wurden Sammlungsaliase für ABC-Klassen in Python 3.9 entfernt.
• Geänderte Funktionssignatur
  • Typ ablehnen, der zuvor akzeptiert wurde (z. B. nur int akzeptieren, float ablehnen).
  • Einen neuen obligatorischen Parameter hinzufügen.
  • Einen positions- oder schlüsselwortbasierten Parameter zu positionsbasiert machen.
• Verhaltensänderung. Zum Beispiel serialisiert Python 3.8 XML-Attribute jetzt in ihrer Einfügungsreihenfolge, anstatt sie nach Namen zu sortieren.
• Neue Warnung. Da immer mehr Projekte mit allen Warnungen als Fehler getestet werden, kann jede neue Warnung dazu führen, dass ein Projekttest fehlschlägt.
• Aus der C-API entfernte Funktion.
• In der C-API eine Struktur als undurchsichtig markieren. Zum Beispiel wurde PyInterpreterState in Python 3.8 undurchsichtig, was Projekte brach, die auf interp->modules zugriffen (stattdessen sollte PyImport_GetModuleDict() verwendet werden).

Python und DeprecationWarning bereinigen

Einer der Mottos von Zen of Python (PEP 20) lautet:

Es sollte einen – und vorzugsweise nur einen – offensichtlichen Weg geben, es zu tun.

Wenn sich Python weiterentwickelt, entstehen zwangsläufig neue Wege. DeprecationWarnings werden ausgegeben, um die Verwendung des neuen Weges vorzuschlagen, aber viele Entwickler ignorieren diese Warnungen, die standardmäßig stumm sind.

Manchmal ist die Unterstützung beider Wege mit geringen Wartungskosten verbunden, aber Python-Kernentwickler ziehen es vor, den alten Weg aufzugeben, um die Codebasis und die Standardbibliothek von Python zu bereinigen. Diese Art von Änderung ist abwärtskompatibel.

Mehr inkompatible Änderungen als üblich sind mit dem Ende der Python 2-Unterstützung zu erwarten, was eine gute Gelegenheit ist, alten Python-Code zu bereinigen.