Zusammenfassung

Diese PEP schlägt vor, Klammern in der Zwei-Argument-Form von assert zuzulassen. Der Interpreter wird assert (expr, msg) als assert expr, msg neu interpretieren und so die häufige Fehlerquelle beseitigen, bei der solcher Code zuvor als Assertion eines Zwei-Elemente- Tuple behandelt wurde, das immer wahrheitsgetreu ist.

Motivation

Es ist ein häufiger Benutzerfehler bei der Verwendung der Form der assert-Anweisung, die die Fehlermeldung enthält, diese in Klammern zu setzen [1] [2]. Dies liegt daran, dass viele Anfänger annehmen, assert sei eine Funktion. Die prominenten unittest-Methoden, insbesondere assertTrue(), erfordern ebenfalls Klammern um die Assertion und die Nachricht.

Leider wird dieser Fehler unbemerkt durchgehen, da die assert immer erfolgreich sein wird [6], da sie als assert-Anweisung interpretiert wird, bei der der Ausdruck ein Zwei-Tupel ist, das immer einen wahrheitsgetreuen Wert hat. Der Fehler tritt auch häufig auf, wenn der Test oder die Beschreibung über eine einzelne Zeile hinaus erweitert wird, da Klammern eine natürliche Möglichkeit dafür sind.

Dies ist so verbreitet, dass seit 3.10 vom Compiler eine SyntaxWarning ausgegeben wird und mehrere Code-Linter [3] [4].

Darüber hinaus erlauben einige andere Anweisungen in der Sprache auf die eine oder andere Weise geklammerte Formen, zum Beispiel import-Anweisungen (from x import (a,b,c)) oder del-Anweisungen (del (a,b,c)).

Das Zulassen von Klammern wird nicht nur die Fehlerquelle beseitigen, sondern auch Benutzern und Autoformatierern ermöglichen, lange assert-Anweisungen über mehrere Zeilen so zu formatieren, wie es die Autoren dieses Dokuments für natürlicher halten. Obwohl es derzeit möglich ist, lange assert-Anweisungen mit Backslashes (wie von PEP 8 empfohlen) oder Klammern und einem Komma über mehrere Zeilen zu formatieren

assert (
  very very long
  test
), (
  "very very long "
  "error message"
)

glauben die Autoren dieses Dokuments, dass die vorgeschlagene geklammerte Form klarer und intuitiver ist und besser mit der Formatierung anderer Grammatikkonstrukte übereinstimmt

assert (
  very very long
  test,

  "very very long "
  "message"
)

Begründung

Aufgrund von Kompatibilitätsbedenken (siehe Abschnitt unten), um Benutzer über die neue Änderung zu informieren, wie ein bisheriges Zwei-Elemente-Tupel geparst wird, wird bis Python 3.17 eine SyntaxWarning mit einer Nachricht wie "neue Assertionssyntax, wird erstes Element des Tupels assertieren" ausgegeben. Zum Beispiel bei Verwendung der neuen Syntax

>>> assert ('Petr' == 'Pablo', "That doesn't look right!")
<python-input-0>:0: SyntaxWarning: new assertion syntax, will assert first element of tuple
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    assert ('Petr' == 'Pablo', "That doesn't look right!")
            ^^^^^^^^^^^^^^^^^
AssertionError: That doesn't look right!

Beachten Sie, dass die Verbesserung von Syntaxwarnungen im Allgemeinen außerhalb des Geltungsbereichs dieser PEP liegt.

Spezifikation

Die formale Grammatik der assert-Anweisung wird geändert zu [8]

| 'assert' '(' expression ',' expression [','] ')' &(NEWLINE | ';')
| 'assert' a=expression [',' expression ]

wobei die erste Zeile die neue Form der assert-Anweisung ist, die Klammern zulässt und bis 3.17 eine SyntaxWarning auslöst. Die Vorausschau ist notwendig, um zu verhindern, dass der Parser das Tupel gierig als vollständige Anweisung erfasst, sodass Anweisungen wie assert (a, b) <= c, "something" weiterhin korrekt geparst werden.

Implementierungs-Hinweise

Diese Änderung kann im Parser oder im Compiler implementiert werden. Die Spezifikation, dass eine SyntaxWarning zur Information der Benutzer über die neue Syntax ausgegeben wird, erschwert die Implementierung, da Warnungen während der Kompilierung ausgegeben werden sollten.

Die Autoren glauben, dass eine ideale Implementierung im Parser erfolgen würde [8], was dazu führt, dass assert (x,y) das gleiche AST wie assert x,y hat. Dies erfordert einen zweistufigen Implementierungsplan mit einem notwendigen vorübergehenden Kompromiss.

>>> print(ast.dump(ast.parse('assert(True, "Error message")'), indent=4))
Module(
    body=[
        Assert(
            test=Constant(value=True),
            msg=Constant(value='Error message'),
            paren_syntax=1)])

Abwärtskompatibilität

Die Änderung ist technisch nicht abwärtskompatibel. Ob zunächst im Parser oder Compiler implementiert, assert (x,y), was derzeit als assert-Anweisung mit einem 2-Tupel als Subjekt interpretiert wird und immer wahrheitsgetreu ist, wird als assert x,y interpretiert.

Andererseits sind assert-Anweisungen dieser Art immer erfolgreich, so dass sie in Benutzercode effektiv nichts tun. Die Autoren dieses Dokuments sind der Meinung, dass diese Inkompatibilität vorteilhaft ist, da sie diese Fälle im Benutzercode hervorhebt, während sie zuvor unbemerkt geblieben wären. Dieser Fall hat seit Python 3.10 bereits eine SyntaxWarning ausgelöst, so dass es eine Deputationsperiode von über 5 Jahren gab. Das fortgesetzte Auslösen einer SyntaxWarning sollte Überraschungen vermeiden.

Die Änderung wird auch zu Änderungen am AST von assert (x,y) führen, was derzeit ist

Module(
    body=[
        Assert(
            test=Tuple(
                elts=[
                    Name(id='x', ctx=Load()),
                    Name(id='y', ctx=Load())],
                ctx=Load()))],
    type_ignores=[])

die endgültige Implementierung, in Python 3.18, wird zu folgendem AST führen

Module(
    body=[
        Assert(
            test=Name(id='x', ctx=Load()),
            msg=Name(id='y', ctx=Load()))],
    type_ignores=[])

Das Problem dabei ist, dass das AST der ersten Form technisch „falsch“ sein wird, da wir bereits eine spezialisierte Form für das AST einer assert-Anweisung mit Test und Nachricht haben (die zweite). Die anfängliche Implementierung im Compiler wird diese Änderung verzögern und Bedenken hinsichtlich der Abwärtskompatibilität ausräumen, da Tools mehr Zeit zum Anpassen haben.

Wie man das lehrt

Die neue Syntax der assert-Anweisung wird als Teil des Sprachstandards dokumentiert.

Beim Lehren der Form mit Fehlermeldung der assert-Anweisung kann nun darauf hingewiesen werden, dass auch das Hinzufügen von Klammern wie erwartet funktioniert, was es ermöglicht, die Anweisung über mehrere Zeilen zu verteilen.

Referenzimplementierung

Eine Referenzimplementierung im Parser ist in diesem Branch zu finden und eine Referenzimplementierung im Compiler in diesem Branch.

Abgelehnte Ideen

assert condition else "message"
assert (condition else "message")

Sicherheitsimplikationen

Für diese Änderung gibt es keine Sicherheitsimplikationen.

Danksagungen

Diese Änderung wurde ursprünglich in python/cpython#90325 diskutiert und vorgeschlagen.

Vielen Dank an Petr Viktorin für seine Hilfe während des Entwurfsprozesses dieser PEP.

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.