Fördert die Verwendung von benannten Argumenten

Indem diese Syntax das visuelle Rauschen reduziert, das die etablierte Syntax für Schlüsselwortargumente verursachen kann, würde sie die Verwendung von benannten Argumenten fördern, wodurch die Lesbarkeit verbessert und Fehler durch Vertauschung von Argumenten reduziert werden.

Reduziert Redundanz

Indem wir visuelles Rauschen und in einigen Fällen Codezeilen minimieren, können wir die Lesbarkeit erhöhen.

Fördert konsistente Variablennamen

Ein häufiges Problem ist, dass semantisch identische Variablen je nach Kontext unterschiedliche Namen haben. Diese Syntax würde Autoren ermutigen, bei der Benennung einer Funktion denselben Variablennamen wie der Argumentname zu verwenden, was die Konsistenz der verwendeten Variablennamen erhöhen und somit die Lesbarkeit verbessern würde.

Hebt Argumente hervor, die diesem Muster nicht folgen

Mit der aktuellen Syntax können Funktionsaufrufe, bei denen viele Argumente aus dem lokalen Kontext weitergeleitet werden, aufgrund des visuellen Rauschens andere Argumentwerte leicht übersehen lassen. Zum Beispiel

add_middleware(
    excluded_urls=excluded_urls,
    server_request=server_request,
    client_request=client_request,
    client_response=client_response,
    span_details=_get_span_details(),
    tracer=tracer,
    meter=meter,
)

Mit dieser Syntax werden die außergewöhnlichen Argumente leichter erkennbar.

add_middleware(
    excluded_urls=,
    server_request=,
    client_request=,
    client_response=,
    span_details=_get_span_details(),
    tracer=,
    meter=,
)

Anwendbarkeit auf Dictionary-Konstruktion

Diese Syntax kann auf die Dictionary-Konstruktion angewendet werden, wo ein ähnliches Muster häufig vorkommt (wobei Dictionary-Schlüssel identisch mit den Namen der Variablen sind, die ihnen als Werte zugewiesen werden), {"x": x, "y": y} oder dict(x=x, y=y). Mit dieser Funktion kann dies nun auch trivial als dict(x=, y=) geschrieben werden. Ob ähnliche Syntax in Dictionary-Literalen weiter unterstützt werden soll, ist eine offene Frage, die über den Umfang dieses PEP hinausgeht.

f(a, b, *, x)

Einige Male wurde die Idee geäußert, die Syntax von schlüsselwort-only Funktionsdefinitionen zu übernehmen.

Für diesen Vorschlag

• Diese Syntax ist vertraut durch ihre Verwendung zur Erforderung von schlüsselwort-only Argumenten in Funktionsdefinitionen.
• Eine Umfrage unter Python-Entwicklern zeigt, dass dies die zweitbeliebteste Syntax unter den vorgeschlagenen ist.

Wir widersprechen jedoch, dass

• Für jedes gegebene Argument ist unklarer aus dem lokalen Kontext, ob es sich um ein Positions- oder ein benanntes Argument handelt. Das * könnte in einer langen Argumentliste leicht übersehen werden, und benannte Argumente könnten als Positions- oder umgekehrt gelesen werden.
• Es ist unklar, ob Schlüsselwortargumente, für die der Wert nicht elidiert wurde, dem * folgen dürfen. Wenn ja, ist ihre relative Position verwirrend-willkürlich, aber wenn nicht, wird eine willkürliche Gruppierung zwischen verschiedenen Arten von Schlüsselwortargumenten erzwungen und die Reihenfolge der Argumente müsste geändert werden, wenn nur ein Name (das Argument oder sein Wert) geändert würde.
• Die Verwendung von * in Funktionsaufrufen ist gut etabliert und dieser Vorschlag würde eine neue Auswirkung einführen, die Verwirrung stiften könnte. Zum Beispiel würde f(a, *x, y) etwas anderes bedeuten als f(a, *, x, y).

f(=x)

Für diese Form

• Der Präfix-Operator ähnelt stärker der etablierten *args und **kwargs Syntax für Funktionsaufrufe.
• Sie fällt stärker auf, wenn Argumente vertikal angeordnet sind. Insbesondere wenn die Argumente unterschiedliche Längen haben, ist es schwieriger, das Gleichheitszeichen am Ende zu finden. Da Python von links nach rechts gelesen wird, ist die Verwendung dieser Funktion dem Leser früher klarer.

Im Gegenteil

• Obwohl die Präfixversion visuell lauter ist, gibt es praktisch keinen Bedarf dafür, dass diese Funktion ihre Anwesenheit lauter schreit als ein typisches benanntes Argument. Bis wir zum = lesen, ist klar, dass der Wert automatisch ausgefüllt wird, genauso wie der Wert im typischen Fall von Schlüsselwortargumenten klar ist.
• Semantisch vermittelt diese Form „hier ist ein Wert, fülle den Parameter aus“, was nicht das ist, was wir vermitteln wollen.
• Sie ähnelt der f-String-Syntax weniger.
• Es ist weniger offensichtlich, dass beliebige Ausdrücke ungültig sind, z. B. f(=a + b), da solche Ausdrücke nach dem Gleichheitszeichen in der aktuellen Syntax für Schlüsselwortargumente zulässig sind, aber nicht davor.

f(%x) oder f(:x) oder f(.x)

Mehrere Varianten dieser Syntax wurden vorgeschlagen, wobei die Präfixform ein anderes Zeichen für = verwendet. Keine solche Form hat sich jedoch durchgesetzt und die Wahl des Symbols scheint im Vergleich zu = willkürlich. Darüber hinaus gibt es weniger Präzedenzfälle in Bezug auf bestehende Sprachfunktionen (wie f-Strings) oder andere Sprachen (wie Ruby).

Die Syntax ist hässlich

Dieser Einwand ist der häufigste. Im Gegenteil, wir argumentieren, dass

• Dieser Einwand ist subjektiv und viele Community-Mitglieder stimmen dem nicht zu.
• Eine fast identische Syntax ist bereits für f-Strings etabliert.
• Programmierer werden sich im Laufe der Zeit anpassen.

Die Funktion ist verwirrend

Wir argumentieren, dass

• Die Einführung neuer Funktionen hat typischerweise vorübergehend diese Auswirkungen.
• Die Syntax ist der etablierten f'{x=}'-Syntax sehr ähnlich.
• Die Funktion und die Syntax sind aus anderen beliebten modernen Sprachen vertraut.
• Die Erweiterung von x= zu x=x ist eine triviale Funktion und von Natur aus deutlich weniger komplex als die beliebten Erweiterungen *arg und **kwarg.
• Diese spezielle Syntaxform wurde unabhängig voneinander mehrfach vorgeschlagen, was darauf hindeutet, dass sie die naheliegendste ist [1] [2] [6].

Die Funktion ist nicht explizit

Wir erkennen an, dass der Wert des Arguments in dieser vorgeschlagenen Syntax offensichtlich „implizit“ ist. Wir glauben jedoch nicht, dass dies das ist, was der Zen of Python zu entmutigen versucht.

In dem Sinne, wie wir den Zen verstehen, sind Schlüsselwortargumente (zum Beispiel) expliziter als Positionsargumente, bei denen der Argumentname weggelassen wird und aus dem lokalen Kontext nicht ersichtlich ist. Umgekehrt ist die Kurzschreibweise für Ganzzahlen x += 1 in diesem Sinne nicht impliziter als x = x + 1, auch wenn die Variable auf der rechten Seite weggelassen wird, da sie aus dem lokalen Kontext sofort ersichtlich ist, was sie ist.

Die in diesem PEP vorgeschlagene Syntax ist viel stärker analog zum Beispiel x += 1 (wenn auch einfacher, da wir keine neue Operation einführen). Darüber hinaus wird durch die Beseitigung der Barriere von visuellem Rauschen, das durch die bestehende Syntax für Schlüsselwortargumente entsteht, diese Kurzschreibweise die Verwendung von Schlüsselwortargumenten gegenüber Positionsargumenten fördern und typische Python-Codebasen im Allgemeinen expliziter machen.

Die Funktion fügt eine weitere Möglichkeit der Ausführung hinzu

Dasselbe Argument kann gegen alle Syntaxänderungen vorgebracht werden. Dies ist eine einfache Kurzschreibweise, ähnlich wie x += 1 eine Kurzschreibweise für x = x + 1 ist, wenn x eine Ganzzahl ist. Dies ist keine „neue Art“ des Übergangs von Argumenten, sondern eine lesbarere Notation für denselben Weg.

Das Umbenennen der Variablen im aufrufenden Kontext bricht den Code

Ein NameError würde den Fehler in den meisten Fällen klarstellen. Es kann zu Verwirrung kommen, wenn eine Variable aus einem breiteren Gültigkeitsbereich denselben Namen wie die ursprüngliche Variable hat, sodass kein NameError ausgelöst wird. Dieses Problem kann jedoch auch bei Schlüsselwortargumenten mit der aktuellen Syntax auftreten (obwohl diese Kurzschreibweise es vielleicht schwieriger macht, es zu erkennen). Darüber hinaus wird die Benennung von Variablen mit demselben Namen in verschiedenen Gültigkeitsbereichen generell als schlechte Praxis angesehen und von Lintern abgemahnt.

Code-Editoren könnten das Problem anhand statischer Analysen hervorheben – f(x=) ist exakt äquivalent zum Schreiben von f(x=x). Wenn x nicht existiert, haben moderne Editoren kein Problem damit, das Problem hervorzuheben.

Diese Syntax erhöht die Kopplung

Wir erkennen an, dass, wie immer, jede Syntax das Potenzial für Missbrauch birgt und daher mit Bedacht angewendet werden sollte, um Codebasen zu verbessern. In diesem Fall, wenn ein Parameter und sein Wert in beiden Kontexten dieselbe Semantik haben, deutet dies darauf hin, dass die Verwendung dieser Syntax angemessen ist und dazu beiträgt, das Risiko einer unbeabsichtigten Desynchronisation zu verringern, die die Lesbarkeit beeinträchtigt.

Wenn die beiden Variablen jedoch unterschiedliche Semantik haben, deutet dies darauf hin, dass diese Funktion nicht verwendet werden sollte (da sie Konsistenz fördert) oder dass eine oder beide Variablen umbenannt werden sollten.

Verwendung eines einfachen Texteditors

Die Bearbeitung mit einem einfachen Texteditor sollte im Allgemeinen nicht beeinträchtigt werden.

Beim Umbenennen einer Variablen mit der Methode „Suchen-Ersetzen“ kommt der Entwickler bei Verwendung dieser Syntax beim Funktionsargument bei der Ausführung auf (wie auch, wenn diese Syntax nicht verwendet worden wäre). An diesem Punkt kann er wie üblich entscheiden, ob er das Argument ebenfalls aktualisieren oder zur vollen f(x=x)-Syntax erweitern möchte.

Wie bei der aktuellen Syntax würde eine Methode „Alles suchen und ersetzen“ fehlschlagen, da das Schlüsselwortargument in den meisten Fällen bei der Funktionsdefinition nicht vorhanden wäre.

Wenn der Entwickler den Argumentnamen unverändert lässt und vergisst, seinen Wert zu aktualisieren, wird in der Regel ein NameError ausgelöst, wie in Das Umbenennen der Variablen im aufrufenden Kontext bricht den Code beschrieben.

Vorschläge für IDEs

Als Reaktion auf das Feedback der Community nehmen wir einige Vorschläge auf, wie IDEs diese Syntax handhaben könnten. Wir überlassen es jedoch den Domänenexperten, die IDEs entwickeln, ihr eigenes Ermessen zu walten zu lassen.

Die meisten Überlegungen werden vereinfacht, indem man erkennt, dass f(x=) nur eine Kurzschreibweise für f(x=x) ist und wie derzeit behandelt werden sollte.