PEPs sind die einzige Spezifikation

Das Python-Typsystem wurde ursprünglich durch ein PEP (PEP 484) geschaffen, und Änderungen am Typsystem werden immer noch durch PEPs vorgenommen. Die Spezifikation für das Python-Typsystem, soweit eine existiert, besteht aus dieser Reihe von PEPs. Aber Standards Track PEPs sind nicht als lebende Dokumente oder Spezifikationen gedacht; sie sind Änderungsvorschläge.

Ein Beispiel kann das Problem hier verdeutlichen. Etwa zur gleichen Zeit wie die Einführung des typing-Moduls durch PEP 484 führte PEP 3156 das asyncio-Modul ein, eine weitere bedeutende Neuerung, die maßgeblich zum Erfolg von Python 3 beigetragen hat. Beide Module haben sich seit ihrer Einführung stark weiterentwickelt und Änderungen am Kern der Sprache inspiriert.

Jedoch unterscheiden sich asyncio und typing in einem wesentlichen Punkt: ein Benutzer, der asyncio verwendet, interagiert nur mit der Standardbibliothek selbst, während ein Benutzer von typing auch ein externes Werkzeug, den Typ-Checker, berücksichtigen muss. Die Python-Sprachreferenz behandelt die Symbole im Typing-Modul, aber sie geht nicht (und sollte nicht) ins Detail darauf eingehen, wie das vollständige Typsystem von Typ-Checkern interpretiert werden soll. Dieses Material existiert derzeit nur in den PEPs.

Dieses Problem teilt sich das Packaging-Ökosystem, das versucht, es durch die Pflege einer separaten Reihe von PyPA-Spezifikationen zu lösen.

Es ist schwierig, die Spezifikation weiterzuentwickeln

Da die PEPs die einzige Spezifikation sind, die wir haben, würde alles, was als Änderung der Spezifikation angesehen werden könnte, theoretisch eine neue PEP erfordern. Aber das ist oft ein zu umständlicher Prozess für eine kleine Änderung. Manchmal werden Änderungen direkt an alten PEPs vorgenommen, aber das widerspricht der Idee, dass akzeptierte und implementierte PEPs historische Dokumente werden, die nicht mehr geändert werden sollten.

Einige konkrete Beispiele sind

• PEP 484 besagt ausdrücklich, dass typing.NoReturn nicht in Argumentannotationen verwendet werden kann. Nichtsdestotrotz haben Typ-Checker die Verwendung schon lange akzeptiert.
• Eine Diskussion von 2023 stellte fest, dass die Beschreibung von partiellen Stubs in PEP 561 unklar ist und große Typ-Checker sie nicht genau wie spezifiziert implementiert haben.
• Das weit verbreitete Drittanbieterpaket typing_extensions bietet Backports neuer Typsystem-Funktionen. Typ-Checker sollen Symbole in diesem Modul genauso behandeln wie Symbole in typing, aber dies ist in keiner der PEPs ausdrücklich spezifiziert.

Das Typsystem ist unterdefiniert

Während die PEPs eine Spezifikation bieten, sind sie oft nicht ausreichend präzise (manchmal absichtlich). Dies gilt insbesondere, da die kombinatorische Komplexität des Typsystems zugenommen hat.

Es liegt an einzelnen Typ-Checkern, zu entscheiden, wie mit unterdefinierten Bereichen umgegangen wird. Wenn Typ-Checker informell koordinieren, entstehen De-facto-Standards, die nirgendwo klar aufgezeichnet sind, was das Typsystem für neue Benutzer weniger zugänglich macht. Zum Beispiel:

• Wie die `@overload`-Abstimmung funktioniert
• Wie ParamSpec mit Methoden funktionieren soll mit Methoden
• Das Konzept von rekursiven Aliassen
• Semantik der Variableninitialisierung
• Erreichbarkeitssemantik von Annotationen für __exit__
• Symbol-Sichtbarkeit
• Verwendung von NoReturn zur Exhaustivitätsprüfung

Der Steering Council ist nicht gut positioniert, um die oben genannten Probleme zu lösen

Der SC hat die gesamte Sprache in seinem Zuständigkeitsbereich und ist nicht gut positioniert, um Entscheidungen zu treffen, die sich ausschließlich auf das Typsystem beziehen – allein schon, weil sie neben ihren anderen Aufgaben keine Zeit haben, sich mit Typsystem-Arkana zu befassen. Dies ähnelt im Geiste den Gründen, warum der Steering Council manchmal PEP-Delegationen nutzt.

Zustimmungen

Dieses PEP wurde von den Maintainern aller großen Typ-Checker unterstützt, darunter Rebecca Chen (pytype), Eric Traut (Pyright) und privat von den Maintainern von mypy und Pyre.

Mandat

Das Mandat des Typing Council ist es, sicherzustellen, dass das Python-Typsystem

• Nützlich: Das Typsystem sollte gängige Anwendungsfälle bedienen. Wie in PEP 484 identifiziert, ist der primäre Anwendungsfall die statische Analyse, aber es gibt andere, wie Laufzeit-Typüberprüfung, statische Kompilierung, IDE-Unterstützung und Dokumentation. Der Typing Council sollte all diese Anwendungsfälle bei Entscheidungen berücksichtigen und offen dafür sein, zusätzliche Anwendungsfälle zu unterstützen, wenn sie auftreten.
• Benutzbar: Das Typsystem sollte für Python-Entwickler einfach zu verwenden sein. Es sollte ergonomisch sein, gut typisierten Python-Code zu schreiben, der von Typ-Checkern akzeptiert wird. Es sollte eine gute Dokumentation für das Typsystem geben.
• Stabil: Mit zunehmender Reife des Typsystems sollten Benutzer darauf vertrauen können, dass ihr typisierter Code weiterhin funktioniert und sie ihr mentales Modell für das Typsystem vertrauen können. Änderungen sollten sorgfältig und so vorgenommen werden, dass Störungen minimiert werden. Dennoch sollte sich das Typsystem weiterentwickeln können, und es ist nicht sinnvoll, dieselben Kompatibilitätsrichtlinien für das Verhalten von Typ-Checkern wie für Python selbst zu verwenden. Selbstverständlich folgt die Existenz und das Laufzeitverhalten von Objekten im typing-Modul der Standard-Kompatibilitätsrichtlinie von Python in PEP 387.

Betrieb und Prozess

Der Rat würde aus drei bis fünf Mitgliedern bestehen, die sich aus prominenten Community-Mitgliedern zusammensetzen, wie z. B. Python-Kernentwicklern und Maintainern von wichtigen Typ-Checkern. Die Mitglieder sollten Personen umfassen, die mit einer Vielzahl von Projekten im Zusammenhang mit Typüberprüfung verbunden sind, was Typ-Checker, CPython, typeshed oder andere Projekte einschließen kann.

Die anfänglichen Mitglieder des Rates sind

• Eric Traut (Pyright; Autor von PEP 647, PEP 681 und PEP 695)
• Guido van Rossum (Kernentwickler; Autor von PEP 484 und PEP 526)
• Jelle Zijlstra (Kernentwickler; typeshed; pyanalyze; Autor von PEP 688 und PEP 702)
• Rebecca Chen (pytype)
• Shantanu Jain (Kernentwickler; typeshed; mypy)

Die aktuelle Mitgliedschaft des Rates ist im Repository python/typing-council verzeichnet.

Es gibt keine Amtszeitbegrenzung für Ratsmitglieder. Ratsmitglieder können ihre Position jederzeit niederlegen. Es wird erwartet, dass jedes Mitglied höchstens fünf aufeinanderfolgende Jahre im Amt ist, bevor es zurücktritt.

Wenn eine Stelle frei wird und noch drei oder mehr Mitglieder übrig sind, entscheidet der Rat selbst, ob er ein neues Mitglied ernennen möchte. Zur Bestimmung von Nachfolgern werden Nominierungen aus der Typisierungs-Community gesammelt. Selbstnominierungen sind erlaubt. Der bestehende Typing Council entscheidet dann über das/die Nachfolgemitglied(er) aus den Nominierten. Es wird erwartet, dass dies per Dekret geschieht, aber der Typing Council kann einen Ersatz auf jede gewünschte Weise wählen, einschließlich einer Abstimmung.

Der Typing Council bleibt dem Steering Council gegenüber rechenschaftspflichtig. Zu jeder Zeit und aus jedem Grund könnte der Steering Council (öffentlich oder privat) eine spezifische Änderung vornehmen oder eine nicht-spezifische Änderung an der Zusammensetzung des Typing Council verlangen.

Wir erkennen an, dass dies keine besonders demokratische Struktur ist und dem Typing Council viel Vertrauen entgegenbringt. Die Python-Community hat jedoch eine lange Erfolgsgeschichte mit nicht besonders demokratischen Strukturen! Wir glauben, dass Selbstverwaltung, wechselnde Mitgliedschaft und Rechenschaftspflicht gegenüber dem Steering Council ausreichen werden, um sicherzustellen, dass der Typing Council die Bedürfnisse der Community erfüllt.

Der Rat würde hauptsächlich durch die Überprüfung von GitHub PRs arbeiten. Regelmäßige Treffen sind wahrscheinlich nicht notwendig, aber der Rat kann Videokonferenzen, einen privaten Chat oder welche anderen Mechanismen auch immer intern festlegen.

Der Rat sollte Transparenz anstreben und alle Entscheidungen öffentlich auf discuss.python.org veröffentlichen, nach Möglichkeit mit Begründung. Vor einer Entscheidung sollte der Rat allen interessierten Community-Mitgliedern die Möglichkeit geben, sich zu äußern. Zwischen dem Beginn einer Diskussion und der Entscheidung des Rates sollten mindestens eine Woche vergehen.

Mitglieder des Rates sind berechtigt, PEPs zu sponsern. Wenn dieses PEP angenommen wird, sollte PEP 1 geändert werden, um diese Tatsache zu vermerken.

Projekte

Hier sind einige Bemühungen, für die ein Typing Council verantwortlich wäre.

Änderungen

Dieses PEP dient als Charta für den Typing Council. Änderungen an seiner Funktionsweise können entweder durch ein neues PEP oder durch eine Änderung dieses PEPs vorgenommen werden. In beiden Fällen würde die Änderung vom Steering Council nach Diskussion in der Community beschlossen.

Erstellung der Spezifikation von Grund auf

Dieses PEP schlägt vor, die Typisierungs-Spezifikation zu erstellen, indem man von den bestehenden PEPs ausgeht und dann die Spezifikation nach Bedarf klärt und verbessert. Einige Mitglieder der Community bevorzugen es, von Grund auf neu zu beginnen und eine neue, formalere Spezifikation zu schreiben, die das gesamte Typsystem abdeckt. Dies könnte eine solidere Grundlage für die Spezifikation bieten.

Dies wäre jedoch ein viel größeres Unterfangen. Die bestehende Formalisierungsbemühung von Kevin Millikin ist ein guter Anfang, aber deckt bisher nur einen Teil von PEP 484 ab. Die Abdeckung des restlichen Typsystems würde wahrscheinlich ein Vielfaches an Aufwand erfordern, wenn wir bedenken, dass wichtige Typsystem-Funktionen wie typing.Protocol, `typing.Literal` und typing.TypedDict erst nach PEP 484 eingeführt wurden. Es ist nicht klar, ob es überhaupt Energie in der Community für ein solch gewaltiges Unterfangen gibt. Selbst wenn sich jemand bereit erklärt, die gesamte Arbeit an der Zusammenstellung einer Spezifikation zu leisten, wäre viel Aufwand von Community-Mitgliedern und Typ-Checker-Maintainern erforderlich, um zu prüfen, ob die Spezifikation das aktuelle Verhalten korrekt widerspiegelt und ob, falls nicht, die Spezifikation oder die Typ-Checker geändert werden sollten.

Das Ausgehen von den bestehenden PEPs führt zu einer Spezifikation von geringerer Qualität, bedeutet aber, dass der Typing Council sofort beginnen kann, überall im Typsystem durch die Verbesserung und Klärung der Spezifikation einen Unterschied zu machen. Eine Formalisierungsbemühung kann immer noch durch schrittweises Ersetzen von Spezifikationsabschnitten fortgesetzt werden.

Alternative Governance-Mechanismen

Ein früherer Entwurf dieses PEPs schlug vor, dass der Steering Council jedes Jahr Mitglieder des Typing Council ernennen sollte. Der aktuelle Steering Council schlug vor, dass es besser wäre, wenn sich der Typing Council selbst organisiert und der Steering Council nicht ständig den Typing Council beaufsichtigen muss.

Alternative Governance-Mechanismen sind möglich, einschließlich demokratischerer, aber diese werfen typischerweise mehrere knifflige Fragen auf, erfordern viel mehr Prozess und sind potenziell spaltender. Siehe zum Beispiel die PEP 8000-Serie oder aktuelle Diskussionen über alternative Governance in anderen Python-Subgemeinschaften. Letztendlich existiert der Typing Council unter der Autorität des Steering Council und kann sich daher auf ihn stützen, um die Governance zu bootstrappen und als Rechenschaftsmechanismus zu dienen.

Nichts tun

Wir hoffen, dass substanzielle Fortschritte bei Projekten erzielt werden, die das Typsystem verbessern, unabhängig davon, ob dieses PEP angenommen wird oder nicht. Wir erwarten, dass Projekte wie die Spezifikation oder die Möglichkeit der PEP-Delegation von einem Typing Council mehr profitieren würden, und Projekte wie die Endbenutzerdokumentation weniger. Sicherlich wird der Engpass wahrscheinlich die Beitragenden-Arbeit sein, nicht die Governance.

Derzeit sind die Werkzeuge, die der Community zur Verfügung stehen, um potenzielle Streitigkeiten zu lösen, entweder die Schaffung eines ungefähren Konsenses oder die Ausübung von Macht durch einzelne Projekte oder Mitwirkende. Letzteres ist zwar sehr wertvoll, aber ein langsamer Prozess, der oft in Untätigkeit endet. Letzteres kann zu einem inkonsistenteren Ökosystem führen. Schließlich machen leicht lesbare Governance-Strukturen die Community zugänglicher und gerechter.