Die Match-Anweisung

Oberflächensyntax

match_stmt: "match" subject_expr ':' NEWLINE INDENT case_block+ DEDENT
subject_expr:
    | star_named_expression ',' star_named_expressions?
    | named_expression
case_block: "case" (guarded_pattern | open_pattern) ':' block

guarded_pattern: closed_pattern 'if' named_expression

open_pattern:
    | as_pattern
    | or_pattern

closed_pattern:
    | wildcard_pattern
    | group_pattern
    | structural_constraint

Abstrakte Syntax

Match(expr subject, match_case* cases)
match_case = (pattern pattern, expr? guard, stmt* body)

Die Regeln star_named_expression, star_named_expressions, named_expression und block sind Teil der Standard-Python-Grammatik.

Offene Muster sind Muster, die aus mehreren Token bestehen und nicht unbedingt durch einen schließenden Begrenzer beendet werden (z. B. __ as x, int() | bool()). Um Mehrdeutigkeit für menschliche Leser zu vermeiden, ist ihre Verwendung auf Top-Level-Muster und Gruppenmuster (Muster, die von Klammern umschlossen sind) beschränkt.

Geschlossene Muster sind Muster, die entweder aus einem einzigen Token bestehen (d. h. __) oder einen schließenden Begrenzer als obligatorischen Bestandteil ihrer Syntax haben (z. B. [as x, as y], object{.x as x, .y as y}).

Wie in PEP 634 sind die Schlüsselwörter match und case Soft-Keywords, d. h. sie sind in anderen grammatikalischen Kontexten keine reservierten Wörter (einschließlich am Zeilenanfang, wenn dort kein Doppelpunkt erwartet wird). Das bedeutet, dass sie nur als Schlüsselwörter in einer Match-Anweisung oder einem Case-Block erkannt werden und in allen anderen Kontexten als Variablennamen oder Argumentnamen verwendet werden dürfen.

Im Gegensatz zu PEP 634 sind Muster explizit als eine neue Art von Knoten im Abstrakten Syntaxbaum definiert – auch wenn die Oberflächensyntax mit vorhandenen Ausdrucksknoten geteilt wird, gibt der Parser einen eindeutigen abstrakten Knoten aus.

Zur Einordnung ist match_stmt eine neue Alternative für compound_statement in der Oberflächensyntax und Match eine neue Alternative für stmt in der abstrakten Syntax.

Muster

Die Top-Level-Oberflächensyntax für Muster ist wie folgt:

open_pattern: # Pattern may use multiple tokens with no closing delimiter
    | as_pattern
    | or_pattern

as_pattern: [closed_pattern] pattern_as_clause

or_pattern: '|'.simple_pattern+

simple_pattern: # Subnode where "as" and "or" patterns must be parenthesised
    | closed_pattern
    | value_constraint

closed_pattern: # Require a single token or a closing delimiter in pattern
    | wildcard_pattern
    | group_pattern
    | structural_constraint

Wie oben beschrieben, ist die Verwendung von offenen Mustern auf Top-Level-Case-Klauseln und beim Klammern in einem Gruppenmuster beschränkt.

Die abstrakte Syntax für Muster gibt explizit an, welche Elemente Unter-Muster und welche Elemente Unter-Ausdrücke oder Bezeichner sind.

pattern = MatchAlways
     | MatchValue(matchop op, expr value)
     | MatchSequence(pattern* patterns)
     | MatchMapping(expr* keys, pattern* patterns)
     | MatchAttrs(expr cls, identifier* attrs, pattern* patterns)
     | MatchClass(expr cls, pattern* patterns, identifier* extra_attrs, pattern* extra_patterns)

     | MatchRestOfSequence(identifier? target)
     -- A NULL entry in the MatchMapping key list handles capturing extra mapping keys

     | MatchAs(pattern? pattern, identifier target)
     | MatchOr(pattern* patterns)

as_pattern: [closed_pattern] pattern_as_clause
pattern_as_clause: 'as' pattern_capture_target
pattern_capture_target: !"__" NAME !('.' | '(' | '=')

MatchAs(pattern? pattern, identifier target)

or_pattern: '|'.simple_pattern+

simple_pattern: # Subnode where "as" and "or" patterns must be parenthesised
    | closed_pattern
    | value_constraint

MatchOr(pattern* patterns)

value_constraint:
    | eq_constraint
    | id_constraint

eq_constraint: '==' closed_expr
id_constraint: 'is' closed_expr

closed_expr: # Require a single token or a closing delimiter in expression
    | primary
    | closed_factor

closed_factor: # "factor" is the main grammar node for these unary ops
    | '+' primary
    | '-' primary
    | '~' primary

MatchValue(matchop op, expr value)
matchop = EqCheck | IdCheck

# Literal patterns
match number:
    case == 0:
        print("Nothing")
    case == 1:
        print("Just one")
    case == 2:
        print("A couple")
    case == -1:
        print("One less than nothing")
    case == (1-1j):
        print("Good luck with that...")

# Additional literal patterns
match value:
    case == True:
        print("True or 1")
    case == False:
        print("False or 0")
    case == None:
        print("None")
    case == "Hello":
        print("Text 'Hello'")
    case == b"World!":
        print("Binary 'World!'")

# Matching by identity rather than equality
SENTINEL = object()
match value:
    case is True:
        print("True, not 1")
    case is False:
        print("False, not 0")
    case is None:
        print("None, following PEP 8 comparison guidelines")
    case is ...:
        print("May be useful when writing __getitem__ methods?")
    case is SENTINEL:
        print("Matches the sentinel by identity, not just value")

# Matching against variables and attributes
from enum import Enum
class Sides(str, Enum):
    SPAM = "Spam"
    EGGS = "eggs"
    ...

preferred_side = Sides.EGGS
match entree[-1]:
    case == Sides.SPAM:  # Compares entree[-1] == Sides.SPAM.
        response = "Have you got anything without Spam?"
    case == preferred_side:  # Compares entree[-1] == preferred_side
        response = f"Oh, I love {preferred_side}!"
    case as side:  # Assigns side = entree[-1].
        response = f"Well, could I have their Spam instead of the {side} then?"

wildcard_pattern: "__"

MatchAlways

match sequence:
    case [__]:               # any sequence with a single element
        return True
    case [start, *__, end]:  # a sequence with at least two elements
        return start == end
    case __:                 # anything
        return False

group_pattern: '(' open_pattern ')'

structural_constraint:
    | sequence_constraint
    | mapping_constraint
    | attrs_constraint
    | class_constraint

sequence_constraint: '[' [sequence_constraint_elements] ']'
sequence_constraint_elements: ','.sequence_constraint_element+ ','?
sequence_constraint_element:
    | star_pattern
    | simple_pattern
    | pattern_as_clause
star_pattern: '*' (pattern_as_clause | wildcard_pattern)

simple_pattern: # Subnode where "as" and "or" patterns must be parenthesised
    | closed_pattern
    | value_constraint

pattern_as_clause: 'as' pattern_capture_target

MatchSequence(pattern* patterns)

MatchRestOfSequence(identifier? target)

mapping_constraint: '{' [mapping_constraint_elements] '}'
mapping_constraint_elements: ','.key_value_constraint+ ','?
key_value_constraint:
    | closed_expr pattern_as_clause
    | closed_expr ':' simple_pattern
    | double_star_capture
double_star_capture: '**' pattern_as_clause

MatchMapping(expr* keys, pattern* patterns)

attrs_constraint:
    | name_or_attr '{' [attrs_constraint_elements] '}'
attrs_constraint_elements: ','.attr_value_pattern+ ','?
attr_value_pattern:
    | '.' NAME pattern_as_clause
    | '.' NAME value_constraint
    | '.' NAME ':' simple_pattern
    | '.' NAME

MatchAttrs(expr cls, identifier* attrs, pattern* patterns)

class_constraint:
    | name_or_attr '(' ')'
    | name_or_attr '(' positional_patterns ','? ')'
    | name_or_attr '(' class_constraint_attrs ')'
    | name_or_attr '(' positional_patterns ',' class_constraint_attrs] ')'
positional_patterns: ','.positional_pattern+
positional_pattern:
    | simple_pattern
    | pattern_as_clause
class_constraint_attrs:
    | '**' '{' [attrs_constraint_elements] '}'

MatchClass(expr cls, pattern* patterns, identifier* extra_attrs, pattern* extra_patterns)

Erfordert explizite Qualifizierung einfacher Namen in Match-Mustern

Die erste Iteration dieses PEP akzeptierte die grundlegende Prämisse von PEP 634, dass die Syntax für iterierbare Entpackung eine gute Grundlage für die Definition einer neuen Syntax für Pattern Matching bieten würde.

Während des Überprüfungsprozesses wurden jedoch zwei Haupt- und eine kleinere Mehrdeutigkeitsprobleme hervorgehoben, die sich direkt aus dieser Kernannahme ergeben.

• Am problematischsten ist, dass bei der standardmäßigen Bindung einfacher Namen, die auf die vorgeschlagene Klassensyntax von PEP 634 erweitert wird, der Konstrukt ATTR=TARGET_NAME an die rechte Seite bindet, ohne das Schlüsselwort as zu verwenden, und das normale Zuweisungs-an-die-linke-Sigil (=) verwendet, um dies zu tun!
• Wenn die standardmäßige Bindung einfacher Namen auf die vorgeschlagene Mapping-Syntax von PEP 634 erweitert wird, bindet der Konstrukt KEY: TARGET_NAME an die rechte Seite, ohne das Schlüsselwort as zu verwenden.
• Die Verwendung eines PEP 634 Capture-Musters zusammen mit einem AS-Muster (TARGET_NAME_1 as TARGET_NAME_2) ergibt ein seltsames Verhalten, das "sowohl links als auch rechts bindet".

Die dritte Überarbeitung dieses PEP trug diesem Problem Rechnung, indem sie die Ausrichtung an der Syntax für iterierbare Entpackung aufgab und stattdessen verlangte, dass alle Verwendungen von leeren einfachen Namen für etwas anderes als eine Variablen-Lookups durch ein vorangestelltes Sigil oder Schlüsselwort qualifiziert werden müssen.

• as NAME: lokale Variablenbindung
• .NAME: Attribut-Lookup
• == NAME: Variablen-Lookup
• is NAME: Variablen-Lookup
• Jede andere Verwendung: Variablen-Lookup

Der Hauptvorteil dieses Ansatzes besteht darin, dass die Interpretation einfacher Namen in Mustern eine lokale Aktivität ist: ein führendes as zeigt eine Namensbindung an, ein führendes . zeigt einen Attribut-Lookup an, und alles andere ist ein Variablen-Lookup (unabhängig davon, ob wir ein Submuster oder einen Subausdruck lesen).

Mit der nun in diesem PEP vorgeschlagenen Syntax lesen sich die oben identifizierten problematischen Fälle nicht mehr schlecht.

• .ATTR as TARGET_NAME ist offensichtlicher eine Bindung als ATTR=TARGET_NAME
• KEY as TARGET_NAME ist offensichtlicher eine Bindung als KEY: TARGET_NAME
• (as TARGET_NAME_1) as TARGET_NAME_2 sind offensichtlicher zwei Bindungen als TARGET_NAME_1 as TARGET_NAME_2

Widerstehe der Versuchung zu raten

PEP 635 untersucht die Art und Weise, wie Pattern Matching in anderen Sprachen verwendet wird, und versucht, diese Informationen zu nutzen, um plausible Vorhersagen darüber zu treffen, wie Pattern Matching in Python verwendet werden wird.

• Der Wunsch, Werte in lokale Namen zu extrahieren, wird *wahrscheinlich* häufiger vorkommen als der Wunsch, gegen in lokalen Namen gespeicherte Werte abzugleichen.
• Der Wunsch nach einem Vergleich per Gleichheit wird *wahrscheinlich* häufiger vorkommen als der Wunsch nach einem Vergleich per Identität.
• Benutzer werden *wahrscheinlich* zumindest in der Lage sein, sich daran zu erinnern, dass leere Namen Werte binden und Attributreferenzen Werte nachschlagen, selbst wenn sie das nicht selbst herausfinden können, ohne die Dokumentation zu lesen oder jemandem davon zu erzählen.

Um es klar auszudrücken: Ich halte diese Vorhersagen tatsächlich für plausibel. Ich glaube jedoch auch nicht, dass wir im Voraus raten müssen: Ich denke, wir können mit einer expliziteren Syntax beginnen, die von den Benutzern verlangt, ihre Absicht mithilfe eines Präfix-Markers anzugeben (entweder as, == oder is), und dann die Situation in ein paar Jahren neu bewerten, basierend darauf, wie Pattern Matching tatsächlich *in Python* verwendet wird.

Zu diesem Zeitpunkt können wir aus mindestens den folgenden Optionen wählen:

• die Entscheidung, dass die explizite Syntax prägnant genug ist und nichts geändert wird.
• Hinzufügen von inferierten Identitätsbeschränkungen für eines oder mehrere der folgenden Elemente: None, ..., True und False.
• Hinzufügen von inferierten Gleichheitsbeschränkungen für andere Literale (potenziell einschließlich komplexer Literale).
• Hinzufügen von inferierten Gleichheitsbeschränkungen für Attribut-Lookups.
• Hinzufügen von entweder inferierten Gleichheitsbeschränkungen oder inferierten Capture-Mustern für leere Namen.

Alle diese Ideen könnten unabhängig voneinander nach ihren eigenen Verdiensten betrachtet werden, anstatt eine potenzielle Barriere für die Einführung von Pattern Matching darzustellen.

Wenn einige dieser syntaktischen Abkürzungen schließlich eingeführt würden, wären sie auch einfach zu erklären im Hinblick auf die zugrunde liegende explizitere Syntax (das führende as, == oder is würde einfach vom Parser abgeleitet, ohne dass der Benutzer es explizit angeben müsste). Auf Implementierungsebene müsste nur der Parser geändert werden, da die bestehenden AST-Knoten wiederverwendet werden könnten.

Interaktion mit Caching von Attribut-Lookups in lokalen Variablen

Eine der Hauptänderungen zwischen diesem PEP und PEP 634 ist die Verwendung von == EXPR für Gleichheitsbeschränkungs-Lookups, anstatt nur NAME.ATTR anzubieten. Die ursprüngliche Motivation dafür war die Vermeidung des semantischen Konflikts mit regulären Zuweisungszielen, bei denen NAME.ATTR bereits in Zuweisungsanweisungen zur Festlegung von Attributen verwendet wird. Wenn NAME.ATTR die *einzige* Syntax für symbolisches Wert-Matching wäre, dann schließen wir präemptiv alle zukünftigen Versuche aus, gegen einzelne Muster mit der bestehenden Zuweisungsanweisungssyntax abzugleichen. Die aktuelle Motivation liegt eher im allgemeinen Wunsch, nicht über die Absicht der Benutzer zu raten, sondern sie stattdessen explizit in der Syntax angeben zu lassen.

Doch selbst innerhalb von Match-Anweisungen hat die name.attr Syntax für Wertmuster eine unerwünschte Wechselwirkung mit der lokalen Variablenzuweisung, bei der routinemäßige Refactorings, die für jede andere Python-Anweisung semantisch neutral wären, eine wesentliche semantische Änderung einführen, wenn sie auf eine PEP 634-Stil Match-Anweisung angewendet werden.

Betrachten Sie den folgenden Code

while value < self.limit:
    ... # Some code that adjusts "value"

Der Attribut-Lookup kann sicher aus der Schleife herausgehoben und nur einmal durchgeführt werden

_limit = self.limit:
while value < _limit:
    ... # Some code that adjusts "value"

Mit dem in diesem PEP vorgeschlagenen Marker-Präfix-basierten Syntaxansatz wären Wertbeschränkungen ähnlich tolerant gegenüber der Refaktorierung von Match-Mustern zur Verwendung einer lokalen Variable anstelle eines Attribut-Lookups, wobei die folgenden beiden Anweisungen funktional äquivalent wären.

match expr:
    case {"key": == self.target}:
        ... # Handle the case where 'expr["key"] == self.target'
    case __:
        ... # Handle the non-matching case

_target = self.target
match expr:
    case {"key": == _target}:
        ... # Handle the case where 'expr["key"] == self.target'
    case __:
        ... # Handle the non-matching case

Im Gegensatz dazu wären bei der Verwendung der Wert- und Capture-Muster von PEP 634, die das Marker-Präfix weglassen, die folgenden beiden Anweisungen nicht äquivalent.

# PEP 634's value pattern syntax
match expr:
    case {"key": self.target}:
        ... # Handle the case where 'expr["key"] == self.target'
    case _:
        ... # Handle the non-matching case

# PEP 634's capture pattern syntax
_target = self.target
match expr:
    case {"key": _target}:
        ... # Matches any mapping with "key", binding its value to _target
    case _:
        ... # Handle the non-matching case

Dieses PEP stellt sicher, dass die ursprüngliche Semantik bei dieser Art von simplistischer Refaktorierung erhalten bleibt: Verwenden Sie == name, um die Interpretation des Ergebnisses als Wertbeschränkung zu erzwingen, und as name für eine Namensbindung.

PEP 634's Vorschlag, nur die Kurzschreibweise ohne explizites Präfix anzubieten, bedeutet, dass die primäre Antwort "Nun, tun Sie das dann nicht, vergleichen Sie nur mit Attributen in Namespaces, vergleichen Sie nicht mit einfachen Namen" lautet.

PEP 622's Walross-Muster-Syntax hatte eine weitere seltsame Wechselwirkung, bei der sie nicht dasselbe Objekt wie der exakt gleiche Walross-Ausdruck im Körper der Case-Klausel binden konnte, aber PEP 634 hat diese Diskrepanz behoben, indem Walross-Muster durch AS-Muster ersetzt wurden (wobei die Tatsache, dass der an den Namen auf der RHS gebundene Wert nicht derselbe Wert ist wie der von der LHS zurückgegebene, ein Standardmerkmal aller Verwendungen des Schlüsselworts "as" ist).

Verwendung bestehender Vergleichsoperatoren als Präfix für Wertbeschränkungen

Wenn der Nutzen eines dedizierten Präfixes für Wertbeschränkungen akzeptiert wird, ist die nächste Frage, welches Präfix genau das sein sollte.

Die erste veröffentlichte Version dieses PEP schlug die bisher ungenutzte ?-Symbol als Präfix für Gleichheitsbeschränkungen und ?is als Präfix für Identitätsbeschränkungen vor. Bei der Überprüfung des PEP legte Steven D’Aprano einen überzeugenden Gegenvorschlag [5] vor, stattdessen die bestehenden Vergleichsoperatoren (== und is) zu verwenden.

Es gab einige Bedenken hinsichtlich == als Präfix, die es davon abhielten, in der ersten Iteration des PEP als Präfix gewählt zu werden.

• Für gängige Anwendungsfälle ist es sogar noch visuell störender als ?, da viele Leute mit PEP 8-geschulten ästhetischen Empfindlichkeiten ein Leerzeichen zwischen ihm und dem folgenden Ausdruck setzen möchten, was es effektiv zu einem 3-Zeichen-Präfix anstelle eines 1-Zeichens macht.
• Wenn es in einem Mapping-Muster verwendet wird, muss ein Leerzeichen zwischen dem : Schlüssel/Wert-Separator und dem == Präfix liegen, sonst wird der Tokenizer sie falsch trennen (es ergibt sich := und = statt : und ==).
• Wenn es in einem OR-Muster verwendet wird, muss ein Leerzeichen zwischen dem | Muster-Separator und dem == Präfix liegen, sonst wird der Tokenizer sie falsch trennen (es ergibt sich |= und = statt | und ==).
• Wenn es in einem PEP 634-Stil Klassenmuster verwendet wird, muss ein Leerzeichen zwischen dem = Schlüsselwort-Separator und dem == Präfix liegen, sonst wird der Tokenizer sie falsch trennen (es ergibt sich == und = statt = und ==).

Anstatt ein völlig neues Symbol einzuführen, bestand Stevens vorgeschlagene Lösung für dieses Ausführlichkeitsproblem darin, die Möglichkeit beizubehalten, das Präfix-Marker in syntaktisch eindeutigen Fällen wegzulassen.

Während die Idee, das Präfix-Marker wegzulassen, für die zweite Revision des Vorschlags akzeptiert wurde, wurde sie in der dritten Revision aufgrund von Mehrdeutigkeitsbedenken wieder verworfen. Stattdessen gelten die folgenden Punkte:

• Für Klassenmuster erlauben andere Syntaxänderungen, Gleichheitsbeschränkungen als .ATTR == EXPR und Identitätsbeschränkungen als .ATTR is EXPR zu schreiben, beides ist sehr gut lesbar.
• Für Mapping-Muster wird der zusätzliche syntaktische Lärm toleriert (zumindest vorerst).
• Für OR-Muster wird der zusätzliche syntaktische Lärm toleriert (zumindest vorerst). Mitgliedschaftsbeschränkungen können jedoch einen zukünftigen Weg bieten, um die Notwendigkeit, OR-Muster mit Gleichheitsbeschränkungen zu kombinieren, zu reduzieren (stattdessen würden die zu prüfenden Werte als Set, Liste oder Tupel gesammelt).

Aus dieser Perspektive galten die Argumente von PEP 635 gegen die Verwendung von ? als Teil der Pattern Matching-Syntax auch für diesen Vorschlag, und so wurde der PEP entsprechend angepasst.

Verwendung von __ als Wildcard-Muster-Marker

PEP 635 liefert einen soliden Grund dafür, dass die Einführung von ? *ausschließlich* als Wildcard-Muster-Marker eine schlechte Idee wäre. Da die Syntax für Wertbeschränkungen von der Verwendung bestehender Vergleichsoperatoren anstelle von ? und ?is auf die Verwendung bestehender Vergleichsoperatoren geändert wurde, gilt dieses Argument auch für diesen PEP.

Wie jedoch von Thomas Wouters in [6] angemerkt, bleibt die Wahl von _ in PEP 634 problematisch, da dies wahrscheinlich bedeutet, dass Match-Muster einen *dauerhaften* Unterschied zu allen anderen Teilen von Python haben würden – die Verwendung von _ in Software-Internationalisierung und an der interaktiven Eingabeaufforderung bedeutet, dass es keinen plausiblen Weg gibt, sie als generischen "übersprungenen Bindungs"-Marker zu verwenden.

__ ist ein alternativer "Dieser Wert wird nicht benötigt"-Marker aus einer Stack Overflow-Antwort [7] (ursprünglich vom Autor dieses PEP gepostet) über die verschiedenen Bedeutungen von _ im bestehenden Python-Code.

Dieser PEP schlägt auch die Übernahme einer Implementierungstechnik vor, die den Geltungsbereich der damit verbundenen Sonderbehandlung von __ auf den Parser beschränkt: Definition eines neuen AST-Knotentyps (MatchAlways) speziell für Wildcard-Marker, anstatt ihn als Name-Knoten an den AST weiterzugeben.

Innerhalb des Parsers bedeutet __ entweder einen regulären Namen oder einen Wildcard-Marker in einem Match-Muster, je nachdem, wo man sich im Parse-Baum befand, aber innerhalb des restlichen Compilers ist Name("__") immer noch ein normaler Variablenname, während MatchAlways() immer ein Wildcard-Marker in einem Match-Muster ist.

Im Gegensatz zu _ gibt es für __ keine anderen Anwendungsfälle, so dass ein plausibler Weg zur Wiederherstellung der Bezeichnerbehandlungs-Konsistenz mit dem Rest der Sprache besteht, indem __ überall in Python für "diese Namensbindung überspringen" steht.

• Im Interpreter selbst wird das Laden von Variablen mit dem Namen __ als veraltet markiert. Dies würde dazu führen, dass das Lesen von __ eine Verwarnung ausgibt, während das Schreiben darauf zunächst unverändert bleibt. Um nicht alle Namensladungen zu verlangsamen, könnte dies dadurch erreicht werden, dass der Compiler zusätzlichen Code für den veralteten Namen erzeugt, anstatt eine Laufzeitprüfung in den Standard-Namensladungs-Opcodes durchzuführen.
• Nach einer angemessenen Anzahl von Releases wird der Parser geändert, um einen neuen SkippedBinding AST-Knoten für alle Verwendungen von __ als Zuweisungsziel zu erzeugen und den Rest des Compilers entsprechend zu aktualisieren.
• Erwägen Sie, __ zu einem echten Hard-Keyword zu machen und nicht zu einem Soft-Keyword.

Dieser Deprecationsweg konnte für _ nicht verfolgt werden, da es keine Möglichkeit gibt, dass der Interpreter zwischen Versuchen, _ zu lesen, wenn es nominell als "egal"-Marker verwendet wird, und legitimen Lesevorgängen von _ als i18n-Textübersetzungsfunktion oder als letztes Statement-Ergebnis an der interaktiven Eingabeaufforderung unterscheidet.

Namen, die mit doppelten Unterstrichen beginnen, sind bereits für die Verwendung durch die Sprache reserviert, sei es für Compile-Time-Konstanten (d. h. __debug__), spezielle Methoden oder das Namens-Mangling von Klassenattributen, so dass die Verwendung von __ hier mit diesem bestehenden Ansatz übereinstimmen würde.

Muster explizit im Abstract Syntax Tree darstellen

PEP 634 diskutiert nicht explizit, wie Match-Anweisungen im Abstract Syntax Tree (AST) dargestellt werden sollen, und überlässt diese Details der Implementierung.

Infolgedessen, obwohl die Referenzimplementierung von PEP 634 definitiv funktioniert (und die Grundlage für die Referenzimplementierung dieses PEP bildete), enthält sie einen signifikanten Designfehler: Trotz der Hinweise in PEP 635, dass Muster als von Ausdrücken getrennt betrachtet werden sollten, stellt die Referenzimplementierung sie als Ausdrucksknoten im AST dar.

Das Ergebnis ist ein AST, der gar nicht so abstrakt ist: Knoten, die völlig unterschiedlich kompiliert werden sollten (da sie Muster und keine Ausdrücke sind), werden auf die gleiche Weise dargestellt, und das Typsystem der Implementierungssprache (z. B. C für CPython) kann keine Hilfe bei der Verfolgung bieten, welche Unterknoten gewöhnliche Ausdrücke und welche Submuster sein sollten.

Anstatt diesen Ansatz fortzusetzen, hat dieser PEP stattdessen einen neuen expliziten "Pattern"-Knoten im AST definiert, der es ermöglicht, die Muster und ihre zulässigen Unterknoten explizit im AST selbst zu definieren, wodurch der Code, der die neue Funktion implementiert, klarer wird und der C-Compiler mehr Unterstützung bei der Verfolgung bietet, wann der Codegenerator mit Mustern oder Ausdrücken umgeht.

Diese Änderung im Implementierungsansatz ist tatsächlich orthogonal zu den Oberflächensyntaxänderungen, die in diesem PEP vorgeschlagen werden, so dass sie auch dann noch übernommen werden könnte, wenn der Rest des PEP abgelehnt würde.

Änderungen an Sequenzmustern

Dieses PEP nimmt im Vergleich zu PEP 634 eine bemerkenswerte Änderung an Sequenzmustern vor.

• Es wird nur die eckige Klammerform des Sequenzmusters unterstützt. Weder offene (keine Begrenzer) noch Tupel-Stil (Klammern als Begrenzer) Sequenzmuster werden unterstützt.

Im Vergleich zu PEP 634 sind Sequenzmuster ebenfalls erheblich von der Änderung betroffen, die eine explizite Qualifizierung von Erfassungsmustern und Wertbeschränkungen erfordert. Dies bedeutet, dass case [a, b, c]: stattdessen als case [as a, as b, as c]: geschrieben werden muss und case [0, 1]: stattdessen als case [== 0, == 1]: geschrieben werden muss.

Da die Syntax für Sequenzmuster nicht mehr direkt aus der Syntax für Iterierbare-Entpackung abgeleitet wird, war es nicht mehr sinnvoll, die syntaktische Flexibilität beizubehalten, die in dem ursprünglichen Syntaxvorschlag rein zur Konsistenz mit der Iterierbare-Entpackung enthalten war.

Die Zulassung von offenen und Tupel-artigen Sequenzmustern erhöhte nicht die Ausdruckskraft, sondern nur die Mehrdeutigkeit der Absicht (insbesondere im Vergleich zu Gruppenmustern) und verleitete die Leser dazu, die Syntax für Musterabgleich als intrinsisch mit der Syntax für Zuweisungsziele verbunden zu betrachten (was die Autoren von PEP 634 mehrfach als unerwünschten Weg bezeichnet haben, den Leser einschlagen, und eine Ansicht, die der Autor dieses PEP nun teilt, obwohl er ihr ursprünglich nicht zustimmte).

Änderungen an Mapping-Mustern

Dieses PEP nimmt zwei bemerkenswerte Änderungen an Zuordnungsmustern im Vergleich zu PEP 634 vor:

• Wert-Erfassung wird als SCHLÜSSEL as NAME geschrieben, anstatt als SCHLÜSSEL: NAME.
• Eine breitere Palette von Schlüsseln ist zulässig: jeder "geschlossene Ausdruck" anstelle von nur Literalen und Attributreferenzen.

Wie oben diskutiert, dient die erste Änderung dazu, sicherzustellen, dass alle Bindungsoperationen mit dem Zielnamen rechts von einem Unterausdruck oder Muster das Schlüsselwort as verwenden.

Die zweite Änderung ist hauptsächlich eine Vereinfachung des Parser- und Codegenerator-Codes durch Wiederverwendung der vorhandenen Ausdruckshandhabungsmechanismen. Die Einschränkung auf geschlossene Ausdrücke soll dazu beitragen, die Mehrdeutigkeit zu reduzieren, wo der Schlüssel-Ausdruck endet und das Musterabgleich beginnt. Dies erlaubt meist eine Obermenge dessen, was PEP 634 erlaubt, mit der Ausnahme, dass komplexe Literale in Klammern geschrieben werden müssen (zumindest vorerst).

Anpassung der Zuordnungsmuster-Beispiele von PEP 635 an die in diesem PEP vorgeschlagene Syntax.

match json_pet:
    case {"type": == "cat", "name" as name, "pattern" as pattern}:
        return Cat(name, pattern)
    case {"type": == "dog", "name" as name, "breed" as breed}:
        return Dog(name, breed)
    case __:
        raise ValueError("Not a suitable pet")

def change_red_to_blue(json_obj):
    match json_obj:
        case { 'color': (== 'red' | == '#FF0000') }:
            json_obj['color'] = 'blue'
        case { 'children' as children }:
            for child in children:
                change_red_to_blue(child)

Zur Referenz die äquivalente PEP 634-Syntax.

match json_pet:
    case {"type": "cat", "name": name, "pattern": pattern}:
        return Cat(name, pattern)
    case {"type": "dog", "name": name, "breed": breed}:
        return Dog(name, breed)
    case _:
        raise ValueError("Not a suitable pet")

def change_red_to_blue(json_obj):
    match json_obj:
        case { 'color': ('red' | '#FF0000') }:
            json_obj['color'] = 'blue'
        case { 'children': children }:
            for child in children:
                change_red_to_blue(child)

Änderungen an Klassmustern

Dieses PEP nimmt mehrere bemerkenswerte Änderungen an Klassenmustern im Vergleich zu PEP 634 vor:

• Die syntaktische Ausrichtung an der Klasseninstanziierung wird als aktiv irreführend und wenig hilfreich aufgegeben. Stattdessen wird eine neue dedizierte Syntax zur Überprüfung zusätzlicher Attribute eingeführt, die sich an Zuordnungsmustern orientiert und nicht an der Klasseninstanziierung.
• Eine neue dedizierte Syntax für einfaches "Duck-Typing", das für jede Klasse funktioniert, wird eingeführt.
• Die spezielle Behandlung verschiedener integrierter und Standardbibliothekstypen wird durch eine allgemeine Prüfung auf die Existenz eines __match_args__-Attributs mit dem Wert None ergänzt.

Wie oben diskutiert, hat die erste Änderung zwei Zwecke:

• Sie dient dazu, sicherzustellen, dass alle Bindungsoperationen mit dem Zielnamen rechts von einem Unterausdruck oder Muster das as-Schlüsselwort verwenden. Die Verwendung von = zur Zuweisung auf der rechten Seite ist besonders problematisch.
• Sie dient dazu, sicherzustellen, dass alle Verwendungen einfacher Namen in Mustern ein Präfix haben, das ihren Zweck anzeigt (in diesem Fall ein führender ., um eine Attributsuche anzuzeigen).

Die syntaktische Ausrichtung an der Klasseninstanziierung wurde ebenfalls generell als wenig hilfreich beurteilt, da Klassenmuster dem Abgleichen von Attributen gegen Muster dienen, während Klasseninstanziierung dem Abgleichen von Aufrufargumenten mit Parametern in Klassenkonstruktoren dient, die überhaupt keine große Ähnlichkeit mit den resultierenden Instanzattributen haben mögen.

Die zweite Änderung soll die Verwendung von Musterabgleich für die "Duck-Typing"-Stilprüfungen erleichtern, die in Python bereits üblich sind.

Der konkrete Syntaxvorschlag für diese Muster entstand aus der Betrachtung von Instanzen als Zuordnungen von Attributnamen zu Werten und der Kombination der Attributsuchsyntax (.ATTR) mit der Zuordnungsmustersyntax {SCHLÜSSEL: MUSTER}, um cls{.ATTR: MUSTER} zu erhalten.

Die Zulassung von cls{.ATTR} mit der gleichen Bedeutung wie cls{.ATTR: __} war eine Frage der Betrachtung des führenden . als ausreichend zur eindeutigen Auflösung des Namensgebrauchs (es ist eindeutig eine Attributreferenz, während der Abgleich mit einem variablen Schlüssel in einem Zuordnungsmuster wohl mehrdeutig wäre).

Die letzte Änderung ergänzt lediglich eine CPython-interne Prüfung in der Referenzimplementierung von PEP 634, indem sie das Standardverhalten festlegt, das Klassen erhalten, wenn sie __match_args__ nicht definieren (der optimierte Schnelldurchlauf für die in PEP 634 genannten integrierten und Standardbibliothekstypen bleibt erhalten).

Die Anpassung des Klassenabgleichsbeispiels, das in PEP 635 verlinkt ist, zeigt, dass für rein positionellen Klassenabgleich die Hauptwirkung von den Änderungen an Wertbeschränkungen und Namensbindung ausgeht, nicht von den Änderungen am Klassenabgleich.

match expr:
    case BinaryOp(== '+', as left, as right):
        return eval_expr(left) + eval_expr(right)
    case BinaryOp(== '-', as left, as right):
        return eval_expr(left) - eval_expr(right)
    case BinaryOp(== '*', as left, as right):
        return eval_expr(left) * eval_expr(right)
    case BinaryOp(== '/', as left, as right):
        return eval_expr(left) / eval_expr(right)
    case UnaryOp(== '+', as arg):
        return eval_expr(arg)
    case UnaryOp(== '-', as arg):
        return -eval_expr(arg)
    case VarExpr(as name):
        raise ValueError(f"Unknown value of: {name}")
    case float() | int():
        return expr
    case __:
        raise ValueError(f"Invalid expression value: {repr(expr)}")

Zur Referenz die äquivalente PEP 634-Syntax.

match expr:
    case BinaryOp('+', left, right):
        return eval_expr(left) + eval_expr(right)
    case BinaryOp('-', left, right):
        return eval_expr(left) - eval_expr(right)
    case BinaryOp('*', left, right):
        return eval_expr(left) * eval_expr(right)
    case BinaryOp('/', left, right):
        return eval_expr(left) / eval_expr(right)
    case UnaryOp('+', arg):
        return eval_expr(arg)
    case UnaryOp('-', arg):
        return -eval_expr(arg)
    case VarExpr(name):
        raise ValueError(f"Unknown value of: {name}")
    case float() | int():
        return expr
    case _:
        raise ValueError(f"Invalid expression value: {repr(expr)}")

Die Änderungen an der Klassensyntax selbst sind relevanter, wenn benannte Attribute geprüft und ihre Werte extrahiert werden, ohne sich auf __match_args__ zu verlassen.

match expr:
    case object{.host as host, .port as port}:
        pass
    case object{.host as host}:
        pass

Vergleichen Sie dies mit dem PEP 634-Äquivalent, bei dem es nicht wirklich klar ist, welche Namen sich auf Attribute des Abgleichssubjekts beziehen und welche Namen sich auf lokale Variablen beziehen.

match expr:
    case object(host=host, port=port):
        pass
    case object(host=host):
        pass

In diesem speziellen Fall ist diese Mehrdeutigkeit unerheblich (da die Attribut- und Variablennamen gleich sind), aber im allgemeinen Fall ist es entscheidend zu wissen, welche was ist, um korrekt über den gelesenen Code zu urteilen.

Abgeleitete Wertbeschränkungen

Wie oben diskutiert, schließt dieses PEP die Möglichkeit nicht aus, zukünftig abgeleitete Gleichheits- und Identitätsbeschränkungen hinzuzufügen.

Diese könnten besonders wertvoll für Literale sein, da es sehr wahrscheinlich ist, dass viele "magische" Zeichenketten und Zahlen mit selbsterklärender Bedeutung direkt in Abgleichsmuster geschrieben werden, anstatt in benannten Variablen gespeichert zu werden. (Denken Sie an Konstanten wie None oder offensichtlich spezielle Zahlen wie 0 und 1 oder Zeichenketten, deren Inhalt genauso beschreibend ist wie jeder Variablenname, anstatt kryptische Prüfungen gegen opake Zahlen wie 739452)

Einige erforderliche Klammern optional machen

Das PEP tendiert derzeit stark dazu, Klammern im Angesicht potenzieller Mehrdeutigkeit zu verlangen.

Es gibt jedoch eine Reihe von Fällen, in denen es zumindest streitbar zu weit geht, meistens AS-Muster mit einem expliziten Muster.

An jeder Position, die ein geschlossenes Muster erfordert, können AS-Muster mit doppelten Klammern beginnen, da das verschachtelte Muster ebenfalls ein geschlossenes Muster sein muss: ((OFFENES MUSTER) as NAME)

Aufgrund der Anforderung, dass das Unter-Muster geschlossen sein muss, sollte es in vielen dieser Fälle (z. B. Sequenzmuster-Unter-Muster) vernünftig sein, GESCHLOSSENES_MUSTER as NAME direkt zu akzeptieren.

Weitere Überlegungen zu diesem Punkt wurden zurückgestellt, da das Optionale-Machen von erforderlichen Klammern eine abwärtskompatible Änderung ist und daher das Lockern von Einschränkungen später fallweise betrachtet werden kann.

Akzeptieren komplexer Literale als geschlossene Ausdrücke

PEP 634s Referenzimplementierung enthält viele spezielle Fälle für binäre Operationen sowohl im Parser als auch im restlichen Compiler, um komplexe Literale zu akzeptieren, ohne beliebige binäre numerische Operationen auf Literalwerten zu akzeptieren.

Idealerweise würde dieses Problem auf Parser-Ebene behandelt, wobei der Parser direkt einen Konstanten AST-Knoten ausgibt, der mit einer komplexen Zahl vorab gefüllt ist. Wenn die Dinge so funktionierten, könnten komplexe Literale über einen ähnlichen Mechanismus wie jedes andere Literal akzeptiert werden.

So werden komplexe Literale jedoch nicht behandelt. Stattdessen werden sie an den AST als reguläre BinOp-Knoten weitergegeben, und dann löst der Constant-Folding-Pass auf dem AST sie zu Constant-Knoten mit einem komplexen Wert auf.

Damit der Parser komplexe Literale direkt auflösen kann, müsste der Compiler den Tokenizer anweisen, einen eigenen Token-Typ für imaginäre Zahlen zu generieren (z. B. INUMBER), was es dem Parser ermöglichen würde, ZAHL + INUMBER und ZAHL - INUMBER getrennt von anderen binären Operationen zu behandeln.

Alternativ könnte ein neuer AST-Knoten-Typ ComplexNumber definiert werden, der es dem Parser ermöglichen würde, die nachfolgenden Compiler-Stufen darüber zu informieren, dass ein bestimmter Knoten speziell ein komplexes Literal sein soll, anstatt eine beliebige binäre Operation. Dann könnte der Parser ZAHL + ZAHL und ZAHL - ZAHL für diesen Knoten akzeptieren, während die AST-Validierung für ComplexNumber sicherstellt, dass der reale und der imaginäre Teil des Literals wie erwartet reale und imaginäre Zahlen sind.

Vorerst hat dieses PEP die Behandlung dieser Frage zurückgestellt und verlangt stattdessen, dass komplexe Literale geklammert werden, um sie in Wertbeschränkungen und als Schlüssel von Zuordnungsmustern verwenden zu können.

Zulassen von negierten Beschränkungen in Match-Mustern

Mit der in diesem PEP vorgeschlagenen Syntax ist es nicht erlaubt, != expr oder is not expr als Abgleichmuster zu schreiben.

Beide Formen haben klare potenzielle Interpretationen als negierte Gleichheitsbeschränkung (d. h. x != expr) und als negierte Identitätsbeschränkung (d. h. x is not expr).

Es ist jedoch bei weitem nicht klar, ob eine der beiden Formen oft genug vorkommen würde, um die dedizierte Syntax zu rechtfertigen, so dass die mögliche Erweiterung bis zu weiterer gemeinschaftlicher Erfahrung mit Abgleichanweisungen zurückgestellt wurde.

Zulassen von Mitgliedschaftsprüfungen in Match-Mustern

Die für Gleichheits- und Identitätsbeschränkungen verwendete Syntax wäre einfach auf Mitgliedschaftsprüfungen erweiterbar: in container.

Ein Nachteil der Vorschläge in diesem PEP und in PEP 634 ist, dass die Überprüfung mehrerer Werte im selben Fall nicht wie eine bestehende Container-Mitgliedschaftsprüfung in Python aussieht.

# PEP 634's literal patterns
match value:
    case 0 | 1 | 2 | 3:
        ...

# This PEP's equality constraints
match value:
    case == 0 | == 1 | == 2 | == 3:
        ...

Die Zulassung abgeleiteter Gleichheitsbeschränkungen nach diesem PEP würde es nur so aussehen lassen wie das Beispiel in PEP 634, es würde immer noch nicht wie die äquivalente if-Anweisungsüberschrift aussehen (if wert in {0, 1, 2, 3}:).

Mitgliedschaftsbeschränkungen würden eine explizitere, aber dennoch prägnante Möglichkeit bieten, zu überprüfen, ob das Abgleichssubjekt in einem Container vorhanden ist, und es würde wie eine normale Containment-Prüfung aussehen.

match value:
    case in {0, 1, 2, 3}:
        ...
    case in {one, two, three, four}:
        ...
    case in range(4): # It would accept any container, not just literal sets
        ...

Eine solche Funktion wäre auch leicht erweiterbar, um alle Arten von Fallklauseln ohne weitere Syntaxaktualisierungen zuzulassen, einfach durch geeignete Definition von __contains__ in einer benutzerdefinierten Klassendefinition.

Obwohl dies eine nützliche Erweiterung zu sein scheint und eine gute Möglichkeit, das Ausführlichkeitsproblem dieses PEP bei der Kombination mehrerer Gleichheitsprüfungen in einem OR-Muster zu lösen, ist sie nicht wesentlich, um Abgleichsanweisungen zu einer wertvollen Ergänzung der Sprache zu machen. Daher scheint es angebrachter, sie in einem separaten Vorschlag zu behandeln, anstatt sie hier aufzunehmen.

Ableiten eines Standardtyps für Instanzattributbeschränkungen

Die dedizierte Syntax für Instanzattributbeschränkungen bedeutet, dass object aus object{.ATTR} weggelassen werden könnte, um {.ATTR} zu erhalten, ohne eine syntaktische Mehrdeutigkeit einzuführen (wenn keine Klasse angegeben wäre, würde object impliziert, genau wie bei der Basisklassenliste in Klassendefinitionen).

Es ist jedoch bei weitem nicht klar, ob das Sparen von sechs Zeichen es schwieriger macht, Zuordnungsmuster von Instanzattributmustern visuell zu unterscheiden, so dass die Zulassung dessen als Thema für mögliche zukünftige Überlegungen zurückgestellt wurde.

Vermeidung von Sonderfällen bei Sequenzmustern

Sequenzmuster in diesem PEP und PEP 634 behandeln derzeit str, bytes und bytearray speziell als **niemals** übereinstimmend mit einem Sequenzmuster.

Diese spezielle Behandlung könnte potenziell entfernt werden, wenn wir eine neue abstrakte Basisklasse collections.abc.AtomicSequence für solche Typen definieren würden, bei denen sie konzeptionell ein einzelnes Element sind, aber dennoch das Sequenzprotokoll implementieren, um wahlfreien Zugriff auf ihre Bestandteile zu ermöglichen.

Ausdruckssyntax zum Abrufen mehrerer Attribute von einer Instanz

Die Syntax für Instanzattributmuster ermöglicht es, dass sie als Grundlage für eine allgemeine Syntax zum Abrufen mehrerer Attribute von einem Objekt in einem einzigen Ausdruck verwendet werden kann.

host, port = obj{.host, .port}

Ähnlich wie Slice-Syntax nur innerhalb von Bracket-Subskripts erlaubt ist, wäre die .attr-Syntax für die Benennung von Attributen nur innerhalb von Brace-Subskripts erlaubt.

Diese Idee ist nicht notwendig, damit Musterabgleich nützlich ist, daher ist sie nicht Teil dieses PEP. Sie wird jedoch als möglicher Weg erwähnt, um Musterabgleich stärker in den Rest der Sprache zu integrieren, anstatt ewig in einer völlig getrennten Welt zu existieren.

Ausdruckssyntax zum Abrufen mehrerer Attribute von einer Instanz

Wenn die Brace-Subskript-Syntax für Instanzattributmusterabgleich akzeptiert und dann auf die allgemeine Extraktion mehrerer Attribute erweitert würde, könnte sie noch weiter erweitert werden, um den Abruf mehrerer Elemente aus Containern basierend auf der für Zuordnungsmuster verwendeten Syntax zu ermöglichen.

host, port = obj{"host", "port"}
first, last = obj{0, -1}

Auch diese Idee ist nicht notwendig, damit Musterabgleich nützlich ist, daher ist sie nicht Teil dieses PEP. Wie beim Abrufen mehrerer Attribute wird sie jedoch als Beispiel dafür aufgenommen, wie die vorgeschlagene Musterabgleichsyntax Ideen zur einfacheren Objekt-Dekonstruktion im Allgemeinen inspirieren kann.

Einschränkung zulässiger Ausdrücke in Wertbeschränkungen und Mapping-Muster-Schlüsseln

Während es technisch durchaus möglich ist, die Arten von Ausdrücken, die in Wertbeschränkungen und Zuordnungsmusterschlüsseln zulässig sind, auf nur Attributsuchen und konstante Literale zu beschränken (wie es PEP 634 tut), gibt es keinen klaren Laufzeitvorteil, dies zu tun. Daher schlägt dieses PEP vor, jede Art von primärem Ausdruck (primäre Ausdrücke sind ein existierender Knotentyp in der Grammatik, der Dinge wie Literale, Namen, Attributsuchen, Funktionsaufrufe, Container-Subskripte, geklammerte Gruppen usw. umfasst) sowie hochpriorisierte unäre Operationen (+, -, ~) auf primäre Ausdrücke zu erlauben.

PEP 635 betont zwar mehrmals, dass Literalmuster und Wertmuster keine vollständigen Ausdrücke sind, aber es wird nie ein konkreter Vorteil genannt, der sich aus dieser Einschränkung ergibt (nur ein theoretischer Appell an die Nützlichkeit, statische Prüfungen von dynamischen Prüfungen zu trennen, was ein Stilprüfungs-Tool immer noch erzwingen könnte, auch wenn der Compiler selbst permissiver ist).

Das letzte Mal, als wir eine solche Einschränkung für Dekorator-Ausdrücke auferlegten, war das Hauptergebnis, dass Benutzer jahrelang mit umständlichen syntaktischen Workarounds leben mussten (wie das Verschachteln beliebiger Ausdrücke in Funktionsaufrufe, die einfach ihr Argument zurückgaben), um das gewünschte Verhalten auszudrücken, bevor die Sprachdefinition schließlich aktualisiert wurde, um beliebige Ausdrücke zuzulassen und den Benutzern ihre eigenen Entscheidungen über die Lesbarkeit zu überlassen.

Die Situation in PEP 634, die eine Ähnlichkeit mit der Situation bei Dekorator-Ausdrücken aufweist, ist, dass beliebige Ausdrücke in Wertmustern technisch unterstützt werden, sie erfordern nur umständliche Workarounds, bei denen entweder alle zu vergleichenden Werte in einer Hilfsklasse angegeben werden müssen, die vor der Abgleichanweisung platziert wird.

# Allowing arbitrary match targets with PEP 634's value pattern syntax
class mt:
    value = func()
match expr:
    case (_, mt.value):
        ... # Handle the case where 'expr[1] == func()'

Oder sie müssen als Kombination aus Erfassungsmuster und Guard-Ausdruck geschrieben werden.

# Allowing arbitrary match targets with PEP 634's guard expressions
match expr:
    case (_, _matched) if _matched == func():
        ... # Handle the case where 'expr[1] == func()'

Dieses PEP schlägt vor, auf solche Workarounds zu verzichten und stattdessen beliebige Wertbeschränkungen von Anfang an zu unterstützen.

match expr:
    case (__, == func()):
        ... # Handle the case where 'expr == func()'

Ob das tatsächliche Schreiben solcher Art von Code eine gute Idee wäre, wäre ein Thema für Stilrichtlinien und Code-Linters, nicht für den Sprachcompiler.

Insbesondere wenn statische Analysatoren bestimmte Arten von dynamischen Prüfungen nicht nachvollziehen können, können sie die zulässigen Ausdrücke zur Analysezeit einschränken, anstatt dass der Compiler sie zur Kompilierzeit einschränkt.

Es gibt auch einige Arten von Ausdrücken, die aufgrund der Muster-Caching-Regel, bei der die Anzahl der Auswertungen des Constraint-Ausdrucks von der Implementierung abhängt, fast sicher zu unsinnigen Ergebnissen führen (z. B. yield, yield from, await). Selbst hier vertritt das PEP die Ansicht, dass Benutzer Unsinn schreiben dürfen, wenn sie es wirklich wollen.

Abgesehen von den kürzlich aktualisierten Dekorator-Ausdrücken, ist eine weitere Situation, in der Pythons formale Syntax volle Ausdrucksfreiheit bietet, die fast nie praktisch genutzt wird, in except-Klauseln: Die zu vergleichenden Ausnahmen sind fast immer einfache Namen, Punktnamen oder Tupel davon, aber die Sprachgrammatik erlaubt an dieser Stelle beliebige Ausdrücke. Dies ist ein guter Hinweis darauf, dass Pythons Benutzerbasis darauf vertrauen kann, verantwortungsbewusst lesbare Wege zur Nutzung permissiver Sprachfunktionen zu finden, indem sie das Schreiben schwer lesbarer Konstrukte vermeidet, auch wenn sie vom Compiler zugelassen werden.

Diese Permissivität bringt einen echten konkreten Vorteil auf der Implementierungsseite: Dutzende Zeilen von Abgleichanweisungs-spezifischem Code im Compiler werden durch einfache Aufrufe des bestehenden Codes zur Kompilierung von Ausdrücken ersetzt (einschließlich der AST-Validierungsphase, der AST-Optimierungsphase, der Symboltabellenanalysephase und der Codegenerierungsphase). Dieser Implementierungsnutzen käme nicht nur CPython zugute, sondern jeder anderen Python-Implementierung, die Unterstützung für Abgleichsanweisungen hinzufügen möchte.

Erfordert die Verwendung von Präfix-Markern für Mapping-Muster-Schlüssel

Der erste (unveröffentlichte) Entwurf dieses Vorschlags schlug vor, dass Zuordnungsmusterschlüssel Wertbeschränkungen sein müssen, genau wie PEP 634 fordert, dass sie gültige Literal- oder Wertmuster sind.

import constants

match config:
    case {== "route": route}:
        process_route(route)
    case {== constants.DEFAULT_PORT: sub_config, **rest}:
        process_config(sub_config, rest)

Die zusätzlichen Zeichen waren jedoch syntaktisch unruhig und im Gegensatz zur Verwendung in Wertbeschränkungen (wo sie sie von Nicht-Muster-Ausdrücken unterscheiden) liefert das Präfix hier keine zusätzlichen Informationen, die nicht bereits durch den Ausdruck als Schlüssel innerhalb eines Zuordnungsmusters vermittelt werden.

Dementsprechend wurde der Vorschlag vereinfacht, das Markierungspräfix von Zuordnungsmusterschlüsseln wegzulassen.

Diese Auslassung stimmt auch mit der Tatsache überein, dass Container sowohl Identitäts- als auch Gleichheitsprüfungen in ihren Lookup-Prozess einbeziehen können – sie verlassen sich nicht rein auf Gleichheitsprüfungen, wie die Verwendung des Gleichheitsbeschränkungspräfixes fälschlicherweise implizieren würde.

Zulassen, dass der Schlüssel/Wert-Separator für Mapping-Wertbeschränkungen weggelassen werden kann

Instanzattributmuster erlauben die Auslassung des Trennzeichens : beim Schreiben von Attributwertbeschränkungen wie case object{.attr == expr}.

Das Anbieten einer ähnlichen Kurzform für Zuordnungswertbeschränkungen wurde in Erwägung gezogen, aber ihre Zulassung ermöglicht zutiefst verwirrende Konstrukte wie case {0 == 0}:, bei denen der Compiler weiß, dass dies der Schlüssel 0 mit der Wertbeschränkung == 0 ist, aber ein menschlicher Leser die tautologische Vergleichsoperation 0 == 0 sieht. Mit dem Schlüssel/Wert-Trenner ist die Absicht auch für einen menschlichen Leser offensichtlicher: case {0: == 0}: