TypeScript

In TypeScript werden Funktionstypen in einer Syntax ausgedrückt, die fast identisch mit der von uns vorgeschlagenen ist, aber das Pfeiltoken ist => und Argumente haben Namen.

(x: int, y: str) => bool

Die Namen der Argumente sind für den Typ eigentlich nicht relevant. So ist zum Beispiel dieser der gleiche Callable-Typ

(a: int, b: str) => bool

Kotlin

Funktionstypen in Kotlin erlauben eine identische Syntax wie die von uns vorgeschlagene, zum Beispiel

(Int, String) -> Bool

Es erlaubt auch optional das Hinzufügen von Namen zu den Argumenten, zum Beispiel

(x: Int, y: String) -> Bool

Wie in TypeScript sind die Argumentnamen (falls vorhanden) nur zur Dokumentation da und nicht Teil des Typs selbst.

Scala

Scala verwendet den Pfeil => für Funktionstypen. Ansonsten ist ihre Syntax dieselbe wie die von uns vorgeschlagene, zum Beispiel

(Int, String) => Bool

Scala hat, wie Python, die Möglichkeit, Funktionsargumente nach Namen bereitzustellen. Funktionstypen können optional Namen enthalten, zum Beispiel

(x: Int, y: String) => Bool

Im Gegensatz zu TypeScript und Kotlin sind diese Namen, falls angegeben, Teil des Typs – jede Funktion, die den Typ implementiert, muss dieselben Namen verwenden. Dies ähnelt dem erweiterten Syntaxvorschlag, den wir in unserem Abschnitt Abgelehnte Alternativen beschreiben.

Funktionsdefinitionen vs. Annotationen für Callable-Typen

In all den oben genannten Sprachen verwenden Typ-Annotationen für Funktionsdefinitionen einen Doppelpunkt : anstelle eines Pfeils ->. Zum Beispiel sieht eine einfache Additionsfunktion in TypeScript so aus

function higher_order(fn: (a: string) => string): string {
  return fn("Hello, World");
}

Scala und Kotlin verwenden im Wesentlichen die gleiche :-Syntax für Rückgabe-Annotationen. Der Doppelpunkt : ergibt in diesen Sprachen Sinn, da sie alle : für Typ-Annotationen von Parametern und Variablen verwenden und die Verwendung für Funktion-Rückgabetypen ähnlich ist.

In Python verwenden wir :, um den Beginn eines Funktionskörpers zu kennzeichnen, und -> für Rückgabe-Annotationen. Infolgedessen gibt es, obwohl unser Vorschlag oberflächlich gesehen derselbe ist wie in diesen anderen Sprachen, einen Kontextunterschied. Es besteht die Möglichkeit für mehr Verwirrung in Python beim Lesen von Funktionsdefinitionen, die Callable-Typen enthalten.

Dies ist ein zentrales Anliegen, zu dem wir Feedback für unseren Entwurf der PEP suchen. Eine Idee, die wir diskutiert haben, ist die Verwendung von => anstelle von, um die Unterscheidung zu erleichtern.

Die ML-Sprachfamilie

Sprachen der ML-Familie, einschließlich F#, OCaml und Haskell, verwenden alle -> zur Darstellung von Funktionstypen. Alle verwenden eine klammerfreie Syntax mit mehreren Pfeilen, zum Beispiel in Haskell

Integer -> String -> Bool

Die Verwendung mehrerer Pfeile, die sich von unserem Vorschlag unterscheidet, ergibt Sinn für Sprachen dieser Familie, da sie automatische Currying von Funktionsargumenten verwenden, was bedeutet, dass eine Mehrfachargumentfunktion wie eine Einfachargumentfunktion agiert, die eine Funktion zurückgibt.

Präzedenz von ->

-> bindet schwächer als andere Operatoren, sowohl innerhalb von Typen als auch in Funktionssignaturen, daher sind die folgenden beiden Callable-Typen äquivalent

(int) -> str | bool
(int) -> (str | bool)

-> assoziiert nach rechts, sowohl innerhalb von Typen als auch in Funktionssignaturen. Daher sind die folgenden Paare äquivalent

(int) -> (str) -> bool
(int) -> ((str) -> bool)

def f() -> (int, str) -> bool: pass
def f() -> ((int, str) -> bool): pass

def f() -> (int) -> (str) -> bool: pass
def f() -> ((int) -> ((str) -> bool)): pass

Da Operatoren enger als -> binden, sind Klammern erforderlich, wenn ein Pfeiltyp als Argument zu einem Operator wie | vorgesehen ist.

(int) -> () -> int | () -> bool      # syntax error!
(int) -> (() -> int) | (() -> bool)  # okay

Wir haben jedes dieser Verhaltensweisen diskutiert und glauben, dass sie wünschenswert sind.

• Union-Typen (dargestellt durch A | B gemäß PEP 604) sind in Funktionssignatur-Rückgaben gültig, daher müssen wir zur Konsistenz Operatoren in der Rückgabeposition zulassen.
• Da Operatoren enger als -> binden, ist es korrekt, dass ein Typ wie bool | () -> bool ein Syntaxfehler sein muss. Wir sollten sicherstellen, dass die Fehlermeldung klar ist, da dies ein häufiger Fehler sein könnte.
• Die Assoziation von -> nach rechts, anstatt explizite Klammern zu verlangen, ist konsistent mit anderen Sprachen wie TypeScript und respektiert das Prinzip, dass gültige Ausdrücke normal substituiert werden können.

async Schlüsselwort

Alle Bindungsregeln gelten weiterhin für asynchrone Callable-Typen.

(int) -> async (float) -> str | bool
(int) -> (async (float) -> (str | bool))

def f() -> async (int, str) -> bool: pass
def f() -> (async (int, str) -> bool): pass

def f() -> async (int) -> async (str) -> bool: pass
def f() -> (async (int) -> (async (str) -> bool)): pass

Nachgestellte Kommas

• Nach dem Vorbild von Funktionssignaturen ist es illegal, ein Komma in einer leeren Argumentenliste zu setzen: (,) -> bool ist ein Syntaxfehler.
• Folgt man wieder dem Vorbild, sind nachgestellte Kommas ansonsten immer erlaubt.

  ((int,) -> bool == (int) -> bool
  ((int, **P,) -> bool == (int, **P) -> bool
  ((...,) -> bool) == ((...) -> bool)
  

Das Zulassen nachgestellter Kommas gibt auch Autoformattern mehr Flexibilität beim Aufteilen von Callable-Typen über mehrere Zeilen, was immer nach Standard-Python-Leerzeichenregeln legal ist.

Verbot von ... als Argumenttyp

Unter normalen Umständen ist jeder gültige Ausdruck dort zulässig, wo wir eine Typ-Annotation wünschen, und ... ist ein gültiger Ausdruck. Dies ist niemals semantisch gültig und alle Typüberprüfer würden es ablehnen, aber die Grammatik würde es zulassen, wenn wir dies nicht explizit verhindern würden.

Da ... als Typ bedeutungslos ist und es Benutzerfreundlichkeitsbedenken gibt, schließt unsere Grammatik dies aus und das Folgende ist ein Syntaxfehler

(int, ...) -> bool

Wir haben entschieden, dass es dafür überzeugende Gründe gab.

• Die Semantik von (...) -> bool unterscheidet sich von (T) -> bool für jeden gültigen Typ T: (...) ist eine spezielle Form, die AnyArguments anzeigt, während T ein Typparameter in der Argumentenliste ist.
• ... wird als Platzhalter-Standardwert verwendet, um ein optionales Argument in Stubs und Callback-Protokollen anzuzeigen. Die Zulassung an der Position eines Typs könnte leicht zu Verwirrung und möglicherweise zu Fehlern aufgrund von Tippfehlern führen.
• Im generischen Typ tuple behandeln wir ... als Sonderfall für "mehr vom Gleichen", z. B. bedeutet tuple[int, ...] ein Tupel mit einem oder mehreren Integern. Wir verwenden ... nicht auf ähnliche Weise in Callable-Typen, daher ist es sinnvoll, dies zu verhindern, um Missverständnisse zu vermeiden.

Inkompatibilität mit anderen möglichen Verwendungen von * und **

Die Verwendung von **P zur Unterstützung von PEP 612 ParamSpec schließt jeden zukünftigen Vorschlag aus, der ein nacktes **<irgendein_Typ> zur Typisierung von kwargs verwendet. Dies scheint akzeptabel, weil

• Wenn wir jemals eine solche Syntax wollen würden, wäre es klarer, trotzdem einen Argumentnamen zu verlangen. Dies würde auch den Typ ähnlicher zu einer Funktionssignatur machen. Mit anderen Worten, wenn wir jemals kwargs in Callable-Typen typisieren würden, würden wir (int, **kwargs: str) gegenüber (int, **str) bevorzugen.
• Die Entpackungssyntax von PEP 646 würde die Verwendung von *<irgendein_Typ> für args ausschließen. Der Fall kwargs ist ähnlich genug, dass dies ein nacktes **<irgendein_Typ> ohnehin ausschließt.

Kompatibilität mit Pfeilbasierter Lambda-Syntax

Nach unserem besten Wissen gibt es keine aktive Diskussion über eine Pfeil-ähnliche Lambda-Syntax, die uns bekannt wäre, aber es lohnt sich dennoch, die Möglichkeiten zu bedenken, die durch die Annahme dieses Vorschlags ausgeschlossen würden.

Es wäre unvereinbar mit diesem Vorschlag, die gleiche klammerbasierte Pfeil-Syntax -> für Lambdas zu übernehmen, z. B. (x, y) -> x + y für lambda x, y: x + y.

Unser Standpunkt ist, dass, wenn wir in Zukunft eine Pfeilsyntax für Lambdas wollen, es eine bessere Wahl wäre, => zu verwenden, z. B. (x, y) => x + y. Viele Sprachen verwenden dasselbe Pfeiltoken für sowohl Lambdas als auch Callable-Typen, aber Python ist einzigartig darin, dass Typen Ausdrücke sind und zu Laufzeitwerten ausgewertet werden müssen. Unser Standpunkt ist, dass dies die Verwendung getrennter Token rechtfertigt und angesichts der bestehenden Verwendung von -> für Rückgabetypen in Funktionssignaturen es kohärenter wäre, -> für Callable-Typen und => für Lambdas zu verwenden.

Bewertung und strukturierte API

Wir beabsichtigen, neue eingebaute Typen zu erstellen, zu denen die neuen AST-Knoten ausgewertet werden, und sie im Modul types bereitzustellen.

Unser Plan ist, eine strukturierte API so bereitzustellen, als wären sie wie folgt definiert.

class CallableType:
    is_async: bool
    arguments: Ellipsis | tuple[CallableTypeArgument]
    return_type: object

class CallableTypeArgument:
    kind: CallableTypeArgumentKind
    annotation: object

@enum.global_enum
class CallableTypeArgumentKind(enum.IntEnum):
    POSITIONAL_ONLY: int = ...
    PARAM_SPEC: int = ...

Die Auswertungsregeln sind in Form des folgenden Pseudocodes ausgedrückt.

def evaluate_callable_type(
    callable_type: ast.CallableType | ast.AsyncCallableType:
) -> CallableType:
    return CallableType(
       is_async=isinstance(callable_type, ast.AsyncCallableType),
       arguments=_evaluate_arguments(callable_type.arguments),
       return_type=evaluate_expression(callable_type.returns),
    )

def _evaluate_arguments(arguments):
    match arguments:
        case ast.AnyArguments():
            return Ellipsis
        case ast.ArgumentsList(posonlyargs):
            return tuple(
                _evaluate_arg(arg) for arg in args
            )
        case ast.ArgumentsListConcatenation(posonlyargs, param_spec):
            return tuple(
                *(evaluate_arg(arg) for arg in args),
                _evaluate_arg(arg=param_spec, kind=PARAM_SPEC)
            )
        if isinstance(arguments, Any
    return Ellipsis

def _evaluate_arg(arg, kind=POSITIONAL_ONLY):
    return CallableTypeArgument(
        kind=POSITIONAL_ONLY,
        annotation=evaluate_expression(value)
    )

Abwärtskompatible API

Um Abwärtskompatibilität mit der bestehenden API von types.Callable zu gewährleisten, die auf den Feldern __args__ und __parameters__ basiert, können wir sie so definieren, als wären sie wie folgt geschrieben.

import itertools
import typing

def get_args(t: CallableType) -> tuple[object]:
    return_type_arg = (
        typing.Awaitable[t.return_type]
        if t.is_async
        else t.return_type
    )
    arguments = t.arguments
    if isinstance(arguments, Ellipsis):
        argument_args = (Ellipsis,)
    else:
        argument_args = (arg.annotation for arg in arguments)
    return (
        *arguments_args,
        return_type_arg
    )

def get_parameters(t: CallableType) -> tuple[object]:
    out = []
    for arg in get_args(t):
        if isinstance(arg, typing.ParamSpec):
            out.append(t)
        else:
            out.extend(arg.__parameters__)
    return tuple(out)

Zusätzliche Verhaltensweisen von types.CallableType

Ähnlich wie bei der A | B-Syntax für Unions, die in PEP 604 eingeführt wurde.

• Die Methode __eq__ sollte äquivalente typing.Callable-Werte als gleich zu Werten behandeln, die mit der eingebauten Syntax konstruiert wurden, und ansonsten wie die __eq__ von typing.Callable funktionieren.
• Die Methode __repr__ sollte eine Pfeil-Syntax-Darstellung erzeugen, die, wenn sie ausgewertet wird, uns wieder eine gleiche Instanz von types.CallableType liefert.

Funktionen als Typen

Eine Idee, die wir uns sehr früh angesehen haben, war, die Verwendung von Funktionen als Typen zu erlauben. Die Idee ist, einer Funktion zu erlauben, für ihre eigene Aufrufsignatur einzustehen, mit ungefähr denselben Semantik wie die __call__ Methode von Callback-Protokollen.

def CallableType(
    positional_only: int,
    /,
    named: str,
    *args: float,
    keyword_only: int = ...,
    **kwargs: str
) -> bool: ...

f: CallableType = ...
f(5, 6.6, 6.7, named=6, x="hello", y="world")  # typechecks as bool

Dies mag eine gute Idee sein, aber wir betrachten es nicht als eine brauchbare Alternative zu aufrufbaren Typen.

• Es wäre schwierig, ParamSpec zu behandeln, was wir als eine kritische Funktion für die Unterstützung betrachten.
• Bei der Verwendung von Funktionen als Typen sind die aufrufbaren Typen keine First-Class-Werte. Stattdessen erfordern sie eine separate, ausserhalb des Zeilenflusses liegende Funktionsdefinition, um einen Typ-Alias zu definieren.
• Es würde nicht mehr Funktionen unterstützen als Callback-Protokolle und scheint eher ein kürzerer Weg, diese zu schreiben, als eine Alternative zu Callable zu sein.

Hybride Schlüsselwort-Pfeil-Syntax

In der Sprache Rust wird ein Schlüsselwort fn verwendet, um Funktionen in vielerlei Hinsicht wie Pythons def anzuzeigen, und aufrufbare Typen werden mit einer hybriden Pfeilsyntax Fn(i64, String) -> bool angezeigt.

Wir könnten das Schlüsselwort def in aufrufbaren Typen für Python verwenden, zum Beispiel könnte unsere boolesche Funktion mit zwei Parametern als def(int, str) -> bool geschrieben werden. Aber wir denken, dass dies Leser verwirren könnte, indem sie denken, def(A, B) -> C sei ein Lambda, insbesondere weil das JavaScript-Schlüsselwort function sowohl für benannte als auch für anonyme Funktionen verwendet wird.

Klammerfreie Syntax

Wir haben eine klammerfreie Syntax in Betracht gezogen, die noch prägnanter gewesen wäre.

int, str -> bool

Wir haben uns dagegen entschieden, da dies visuell nicht so ähnlich zur bestehenden Funktionskopf-Syntax ist. Außerdem ist es visuell ähnlich zu Lambdas, die Namen ohne Klammern binden: lambda x, y: x == y.

Erfordernis äußerer Klammern

Ein Bedenken bei dem aktuellen Vorschlag ist die Lesbarkeit, insbesondere wenn aufrufbare Typen in der Rückgabe-Typ-Position verwendet werden, was zu mehreren Top-Level -> Token führt, zum Beispiel.

def make_adder() -> (int) -> int:
    return lambda x: x + 1

Wir haben einige Ideen in Betracht gezogen, um dies zu verhindern, indem wir Regeln bezüglich Klammern ändern. Eine war, die Klammern nach aussen zu verschieben, so dass eine boolesche Funktion mit zwei Argumenten als (int, str -> bool) geschrieben wird. Mit dieser Änderung wird das obige Beispiel zu

def make_adder() -> (int -> int):
    return lambda x: x + 1

Dies macht die Verschachtelung vieler Beispiele, die schwer zu verfolgen sind, klar, aber wir haben sie abgelehnt, weil.

• Derzeit binden Kommas in Python sehr locker, was bedeutet, dass es üblich sein könnte, (int, str -> bool) als Tupel zu missverstehen, dessen erstes Element ein Integer ist, anstatt eines zweistelligen aufrufbaren Typs.
• Es ist der Funktionskopf-Syntax nicht sehr ähnlich, und eines unserer Ziele war vertraute Syntax, inspiriert von Funktionsköpfen.
• Diese Syntax mag für tief verschachtelte aufrufbare Typen wie die obige besser lesbar sein, aber tiefe Verschachtelung ist nicht sehr üblich. Die Ermutigung zu zusätzlichen Klammern um aufrufbare Typen in der Rückgabeposition durch einen Styleguide hätte die meisten Lesbarkeitsvorteile ohne die Nachteile.

Wir haben auch in Betracht gezogen, Klammern sowohl für die Parameterliste als auch für die Aussenseite zu verlangen, z. B. ((int, str) -> bool). Mit dieser Änderung wird das obige Beispiel zu

def make_adder() -> ((int) -> int):
    return lambda x: x + 1

Wir haben diese Änderung abgelehnt, weil.

• Die äusseren Klammern helfen nur in einigen Fällen bei der Lesbarkeit, hauptsächlich wenn ein aufrufbarer Typ in der Rückgabeposition verwendet wird. In vielen anderen Fällen beeinträchtigen sie die Lesbarkeit eher, als sie zu helfen.
• Wir stimmen zu, dass es sinnvoll sein könnte, äussere Klammern in mehreren Fällen zu empfehlen, insbesondere für aufrufbare Typen in Funktionsrückgabe-Annotationen. Aber.
  • Wir glauben, dass es angemessener ist, dies in Styleguides, Linters und Autoformattern zu empfehlen, als es in den Parser einzubacken und Syntaxfehler auszulösen.
  • Darüber hinaus können wir, wenn ein Typ komplex genug ist, dass Lesbarkeit ein Problem darstellt, immer Typ-Aliase verwenden, zum Beispiel.

    IntToIntFunction: (int) -> int
    
    def make_adder() -> IntToIntFunction:
        return lambda x: x + 1
    

Binden von -> enger als |

Um sowohl -> als auch | Token in Typausdrücken zuzulassen, mussten wir eine Präzedenzordnung wählen. Im aktuellen Vorschlag handelt es sich um eine Funktion, die ein optionales boolesches Ergebnis zurückgibt.

(int, str) -> bool | None  # equivalent to (int, str) -> (bool | None)

Wir haben überlegt, -> stärker binden zu lassen, so dass der Ausdruck stattdessen als ((int, str) -> bool) | None geparst würde. Dies hat zwei Vorteile.

• Es bedeutet, dass wir None | (int, str) -> bool nicht mehr als Syntaxfehler behandeln müssten.
• Wenn wir uns heute Typeshed ansehen, sind optionale aufrufbare Argumente sehr üblich, da die Verwendung von None als Standardwert eine Standard-Python-Idiom ist. Wenn -> stärker binden würde, wäre dies einfacher zu schreiben.

Wir haben uns aus mehreren Gründen dagegen entschieden.

• Der Funktionskopf def f() -> int | None: ... ist legal und zeigt eine Funktion an, die ein optionales Integer zurückgibt. Um mit Funktionsköpfen konsistent zu sein, sollten aufrufbare Typen dasselbe tun.
• TypeScript ist die andere populäre Sprache, die uns bekannt ist und sowohl -> als auch | Token in Typausdrücken verwendet, und sie haben |, das stärker bindet. Obwohl wir ihrem Beispiel nicht folgen müssen, tun wir dies vor.
• Wir erkennen an, dass optionale aufrufbare Typen üblich sind und dass | stärker bindet, was zusätzliche Klammern erzwingt und diese Typen schwerer zu schreiben macht. Aber Code wird öfter gelesen als geschrieben, und wir glauben, dass das Erfordernis der äusseren Klammern für einen optionalen aufrufbaren Typ wie ((int, str) -> bool) | None für die Lesbarkeit vorzuziehen ist.

Einführung von Typ-Strings

Eine weitere Idee war, eine neue "spezielle Zeichenketten"-Syntax hinzuzufügen und den Typ darin einzubetten, zum Beispiel t”(int, str) -> bool”. Wir haben dies abgelehnt, weil es nicht so lesbar ist und im Widerspruch zu den Richtlinien des Steering Council steht, um sicherzustellen, dass Typausdrücke nicht von der übrigen Syntax von Python abweichen.

Verbesserung der Benutzerfreundlichkeit des indizierten Callable-Typs

Wenn wir keine neue Syntax für aufrufbare Typen hinzufügen wollen, könnten wir uns ansehen, wie der vorhandene Typ leichter zu lesen ist. Ein Vorschlag wäre, die eingebaute callable Funktion indizierbar zu machen, so dass sie als Typ verwendet werden könnte.

callable[[int, str], bool]

Diese Änderung wäre analog zu PEP 585, die eingebaute Sammlungen wie list und dict als Typen verwendbar machte und Importe bequemer machen würde, aber sie würde die Lesbarkeit der Typen selbst nicht wesentlich verbessern.

Um die Anzahl der Klammern in komplexen aufrufbaren Typen zu reduzieren, wäre es möglich, Tupel für die Argumentliste zuzulassen.

callable[(int, str), bool]

Dies ist tatsächlich eine signifikante Verbesserung der Lesbarkeit für Funktionen mit mehreren Argumenten, aber das Problem ist, dass es Aufrufbare mit einem Argument, die die häufigste Kardinalität sind, schwer zu schreiben macht: da (x) zu x ausgewertet wird, müssten sie als callable[(int,), bool] geschrieben werden. Wir finden das umständlich.

Darüber hinaus helfen keine dieser Ideen so sehr bei der Reduzierung der Ausführlichkeit wie der aktuelle Vorschlag, noch führen sie zu einer so starken visuellen Kennzeichnung wie dem -> zwischen den Parametertypen und dem Rückgabetyp.

Alternative APIs

Wir haben überlegt, ob die Laufzeitdaten types.CallableType eine strukturiertere API verwenden sollten, mit separaten Feldern für posonlyargs und param_spec. Der aktuelle Vorschlag wurde von der inspect.Signature Typ inspiriert.

Wir verwenden "argument" in unseren Feld- und Tynamen, im Gegensatz zu "parameter" wie in inspect.Signature, um Verwechslungen mit dem Feld callable_type.__parameters__ aus der Legacy-API zu vermeiden, das sich auf Typparameter und nicht auf aufrufbare Parameter bezieht.

Verwendung des reinen Rückgabetyps in __args__ für asynchrone Typen

Es ist umstritten, ob wir die Abwärtskompatibilität von __args__ für asynchrone aufrufbare Typen wie async (int) -> str erhalten müssen. Der Grund ist, dass man argumentieren könnte, dass sie nicht direkt mit typing.Callable ausgedrückt werden können und es daher in Ordnung wäre, __args__ als (int, int) anstelle von (int, typing.Awaitable[int]) festzulegen.

Aber wir glauben, dass dies problematisch wäre. Indem wir das Erscheinungsbild einer abwärtskompatiblen API beibehalten, aber ihre Semantik für asynchrone Typen tatsächlich brechen, würden wir Laufzeit-Typbibliotheken, die versuchen, Callable unter Verwendung von __args__ zu interpretieren, stillschweigend fehlschlagen lassen.

Aus diesem Grund wickeln wir den Rückgabetyp automatisch in Awaitable.