PEP 645 – Zulassen der Schreibweise optionaler Typen als x?
- Autor:
- Maggie Moss <maggiebmoss at gmail.com>
- Sponsor:
- Guido van Rossum <guido at python.org>
- Status:
- Zurückgezogen
- Typ:
- Standards Track
- Erstellt:
- 25-Aug-2020
- Resolution:
- Typing-SIG Nachricht
Zusammenfassung
Dieses PEP schlägt die Hinzufügung eines ?-Operators für Typen vor, um int? anstelle von Optional[int] schreiben zu können.
Rücknahme eines PEP
Die durch PEP 604 eingeführte Notation T|None zum Schreiben von Optional[T] ist eine gute Alternative zu T? und erfordert keine neue Syntax.
Die Verwendung von T? im Sinne von T|None ist auch inkonsistent mit TypeScript, wo es grob NotRequired[T] bedeutet. Eine solche Inkonsistenz würde Personen, die von TypeScript zu Python wechseln, wahrscheinlich verwirren.
Das Obige repräsentiert den Konsens von typing-sig und dem Sponsor dieses PEP.
Motivation
Typen sind zu einem wertvollen und mächtigen Teil der Python-Sprache geworden. Viele Typannotationen sind jedoch umständlich und erschweren die Verwendung von Typannotationen erheblich. Durch die Verbesserung der Typensyntax wird das Hinzufügen von Typen zu Python-Code einfacher und verbessert die Entwicklungserfahrung für Python-Benutzer.
In ähnlicher Weise wurde ein PEP zur Einführung einer Kurzschreibweise für Union-Typen genehmigt und implementiert.
Begründung
Typen in Python können recht umständlich sein, was die Einführung von Typen behindern kann. Typen ergonomischer zu gestalten, wie es mit dem Union-Typ in PEP 604 (z. B. int | str) geschehen ist, würde den Aufwand für das Hinzufügen von Typen zu neuen und bestehenden Python-Codes reduzieren. Die Optionale Annotation wird in partiell und vollständig typisierten Python-Codebasen häufig verwendet. In einer kleinen Stichprobe von 5 gut typisierten Open-Source-Projekten enthielten im Durchschnitt 7 % der Annotationen mindestens einen optionalen Typ. Dies deutet darauf hin, dass die Aktualisierung der Syntax das Potenzial hat, Typen prägnanter zu machen, die Code-Länge zu reduzieren und die Lesbarkeit zu verbessern.
Die Vereinfachung der Syntax für optionale Typen wurde innerhalb der Typgemeinschaft bereits früher diskutiert. Der Konsens während dieser Gespräche war, dass ? der bevorzugte Operator ist. Es gibt keine native Unterstützung für unäres ? in Python und dies muss zur Laufzeit hinzugefügt werden.
Das Hinzufügen des ? Sigils zur Python-Grammatik wurde zuvor in PEP 505 vorgeschlagen, das sich derzeit in einem aufgeschobenen Zustand befindet. PEP 505 schlägt einen
- „None coalescing“-Binäroperator
??- „None-aware attribute access“-Operator
?.(„maybe dot“)- „None-aware indexing“-Operator
?[](„maybe subscript“)
Sollte PEP 505 in Zukunft genehmigt werden, würde dies die in diesem PEP vorgeschlagene typspezifische Verwendung von ? nicht beeinträchtigen. Da alle Verwendungen von ? konzeptionell zusammenhängend wären, wäre dies weder verwirrend im Sinne des Lernens von Python noch ein Hindernis für ein schnelles visuelles Verständnis.
Die vorgeschlagene Syntax mit dem Postfix-Operator spiegelt die optionale Syntax anderer typisierter Sprachen wie C#, TypeScript und Swift wider. Die weite Verbreitung und Beliebtheit dieser Sprachen bedeutet, dass Python-Entwickler wahrscheinlich bereits mit dieser Syntax vertraut sind.
// Optional in Swift
var example: String?
// Optional in C#
string? example;
Das Hinzufügen dieser Syntax würde auch dem häufig verwendeten Muster folgen, integrierte Typen als Annotationen zu verwenden. Zum Beispiel list, dict und None. Dies würde es ermöglichen, mehr Annotationen zu Python-Code hinzuzufügen, ohne aus typing importieren zu müssen.
Spezifikation
Die neue optionale Syntax sollte für Funktions-, Variablen-, Attribut- und Parameterannotationen akzeptiert werden.
# instead of
# def foo(x: Optional[int], y: Optional[str], z: Optional[list[int]): ...
def foo(x: int?, y: str?, x: list[int]?): ...
# def bar(x: list[typing.Optional[int]]): ...
def bar(x: list[int?]): ...
Die neue optionale Syntax sollte mit der vorhandenen typing.Optional-Syntax äquivalent sein.
typing.Optional[int] == int?
Die neue optionale Syntax sollte die gleiche Identität wie die vorhandene typing.Optional-Syntax haben.
typing.Optional[int] is int?
Sie sollte auch äquivalent zu einer Union mit None sein.
# old syntax
int? == typing.Union[int, None]
# new syntax
int? == int | None
Da die neue Union-Syntax, die in PEP 604 spezifiziert ist, in isinstance und issubclass unterstützt wird, sollte die neue optionale Syntax sowohl in isinstance als auch in issubclass unterstützt werden.
isinstance(1, int?) # true
issubclass(Child, Super?) # true
Eine neue dunder-Methode muss implementiert werden, um zu ermöglichen, dass der ?-Operator für andere Funktionalitäten überladen wird.
Abwärtskompatibilität
? ist derzeit in der Python-Syntax ungenutzt, daher ist dieses PEP vollständig abwärtskompatibel.
Referenzimplementierung
Eine Referenzimplementierung finden Sie hier.
Abgelehnte Ideen
Diskutierte Alternativen waren
- Der
~-Operator wurde anstelle von?in Betracht gezogen. - Ein Präfix-Operator (
?int).
Urheberrecht
Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.
Quelle: https://github.com/python/peps/blob/main/peps/pep-0645.rst
Zuletzt geändert: 2025-02-01 08:55:40 GMT