Zusammenfassung

Dieses PEP [1] schlägt vor, unklammerte except und except* Blöcke in der Python-Ausnahmebehandlungs-Syntax nur dann zuzulassen, wenn die as Klausel nicht verwendet wird. Derzeit sind bei der Behandlung mehrerer Ausnahmen Klammern um die Ausnahmetypen erforderlich. Dies war ein Überbleibsel aus Python 2. Dieses PEP schlägt vor, das Weglassen dieser Klammern zu erlauben, was die Syntax vereinfacht, sie konsistenter mit anderen Teilen der Syntax macht, bei denen Klammern optional sind, und in bestimmten Fällen die Lesbarkeit verbessert.

Motivation

Die aktuelle Syntax zur Behandlung mehrerer Ausnahmen erfordert Klammern im except Ausdruck (äquivalent für den except* Ausdruck). Zum Beispiel

try:
    ...
except (ExceptionA, ExceptionB, ExceptionC):
    ...

Obwohl diese Syntax klar und unzweideutig ist, kann sie in manchen Fällen als unnötig wortreich angesehen werden, insbesondere wenn eine große Anzahl von Ausnahmen abgefangen wird. Durch das Zulassen des Weglassens von Klammern können wir die Syntax vereinfachen

try:
    ...
except ExceptionA, ExceptionB, ExceptionC:
    ...

Diese Änderung würde die Syntax stärker an andere durch Kommas getrennte Listen in Python angleichen, wie z.B. Funktionsargumente, Generatorausdrücke innerhalb eines Funktionsaufrufs und Tupel-Literale, bei denen Klammern optional sind.

Die gleiche Änderung würde auch für except* Ausdrücke gelten. Zum Beispiel

try:
    ...
except* ExceptionA, ExceptionB, ExceptionC:
    ...

Wenn die as Klausel verwendet wird, um die Ausnahmeinstanz zu erfassen, müssen wie zuvor Klammern verwendet werden. Einige Benutzer haben geäußert, dass sie es verwirrend finden würden, keine Klammern zu verlangen, da unklar wäre, was genau dem Ziel zugewiesen wird, da in anderen Teilen der Sprache mehrere as Klauseln in ähnlichen Situationen verwendet werden können (wie bei Imports und Kontextmanagern). Das bedeutet, dass, wenn eine as Klausel zum vorherigen Beispiel hinzugefügt wird, dies so geschehen muss

try:
    ...
except (ExceptionA, ExceptionB, ExceptionC) as e:
    ...

Begründung

Die Entscheidung, unklammerte except Blöcke zuzulassen, basiert auf den folgenden Überlegungen

1. Einfachheit: Das Wegfallen der Klammern vereinfacht die Syntax und macht sie konsistenter mit anderen Teilen der Sprache.
2. Lesbarkeit: In Fällen, in denen viele Ausnahmen abgefangen werden, kann das Wegfallen von Klammern die Lesbarkeit verbessern, indem die visuelle Unordnung reduziert wird.
3. Konsistenz: Diese Änderung macht die except Klausel konsistenter mit anderen Teilen von Python, wo eindeutige, durch Kommas getrennte Listen keine Klammern erfordern.

Spezifikation

Die Syntax für die except-Klausel wird geändert, um eine unklammerte Liste von Ausnahmetypen zuzulassen. Die Grammatik wird wie folgt aktualisiert

except_block:
    | 'except' expressions ':' block
    | 'except' expression 'as' NAME ':' block
    | 'except' ':' block

except_star_block
    | 'except' '*' expressions ':' block
    | 'except' '*' expression 'as' NAME ':' block

Dies erlaubt sowohl die aktuelle geklammerte Syntax als auch die neue unklammerte Syntax, erfordert aber Klammern, wenn das Schlüsselwort as verwendet wird

try:
    ...
except (ExceptionA, ExceptionB):  # Still valid
    ...
except ExceptionC, ExceptionD:    # New syntax
    ...
except (ExceptionE, ExceptionF) as e: # Parentheses still required
    ...

Die Semantik der Ausnahmebehandlung bleibt unverändert. Der Interpreter fängt jede der aufgeführten Ausnahmen ab, unabhängig davon, ob sie geklammert sind oder nicht.

Abwärtskompatibilität

Diese Änderung ist vollständig abwärtskompatibel. Alle bestehenden Codes, die geklammerte except und except* Blöcke verwenden, funktionieren weiterhin ohne Änderungen. Die neue Syntax ist rein additiv und bricht keinen bestehenden Code.

Es ist erwähnenswert, dass in Python 2 die unklammerte Syntax mit zwei Elementen erlaubt war, aber eine andere Semantik hatte, bei der das erste Element der Liste als Ausnahmetyp und das zweite Element als Erfassungsvariable verwendet wurde. Diese Änderung führt die Python 2-Semantik nicht wieder ein, und die unklammerte Syntax verhält sich identisch zur geklammerten Version.

Sicherheitsimplikationen

Für diese Änderung gibt es keine bekannten Sicherheitsauswirkungen. Die Semantik der Ausnahmebehandlung bleibt gleich, und dies ist rein eine syntaktische Änderung.

Wie man das lehrt

Für neue Python-Benutzer kann die unklammerte Syntax als Standardmethode zum Abfangen mehrerer Ausnahmen gelehrt werden

try:
    risky_operation()
except ValueError, TypeError, OSError:
    handle_errors()

Für erfahrene Benutzer kann sie als neue, optionale Syntax eingeführt werden, die austauschbar mit der geklammerten Version verwendet werden kann. Die Dokumentation sollte darauf hinweisen, dass beide Formen gleichwertig sind

# These are equivalent:
except (ValueError, TypeError):
    ...

except ValueError, TypeError:
    ...

Es sollte betont werden, dass dies rein eine syntaktische Änderung ist und das Verhalten der Ausnahmebehandlung nicht beeinflusst.

Referenzimplementierung

Eine Proof-of-Concept-Implementierung ist verfügbar unter https://github.com/pablogsal/cpython/commits/notuples/. Diese Implementierung modifiziert den Python-Parser, um die neue Syntax zu akzeptieren und stellt sicher, dass sie sich identisch zur geklammerten Version verhält.

Abgelehnte Ideen

1. Zulassen von gemischter geklammerter und unklammerter Syntax

   try:
       ...
   except (ValueError, TypeError), OSError:
      ...
   

   Dies wurde aufgrund der möglichen Verwirrung und zur Wahrung einer klaren Unterscheidung zwischen den beiden Stilen abgelehnt.

Zurückgestellte Ideen

1. Zulassen von unklammerte Ausdrücken, wenn das Schlüsselwort as verwendet wird. Der Grund, warum wir uns entschieden haben, diese spezielle Form zu verschieben, ist, dass es keinen klaren Konsens in irgendeine Richtung gibt und es vernünftige Argumente für beide Positionen gibt. Der sicherste Ansatz ist, die Klammeranforderung beizubehalten, da sie später entfernt werden kann, wenn Benutzer den Bruch als zu stark empfinden, während sie ihn wegzunehmen und die Benutzer feststellen, dass es eine schlechte Idee war, macht es nicht einfach, ihn wieder einzuführen.

Fußnoten

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.