7. Einfache Anweisungen

Eine einfache Anweisung ist in einer einzelnen logischen Zeile enthalten. Mehrere einfache Anweisungen können in einer einzigen Zeile durch Semikolons getrennt vorkommen. Die Syntax für einfache Anweisungen lautet:

simple_stmt: expression_stmt
             | assert_stmt
             | assignment_stmt
             | augmented_assignment_stmt
             | annotated_assignment_stmt
             | pass_stmt
             | del_stmt
             | return_stmt
             | yield_stmt
             | raise_stmt
             | break_stmt
             | continue_stmt
             | import_stmt
             | future_stmt
             | global_stmt
             | nonlocal_stmt
             | type_stmt

7.1. Ausdrucksanweisungen

Ausdrucksanweisungen werden (hauptsächlich interaktiv) verwendet, um einen Wert zu berechnen und auszugeben, oder (normalerweise) um eine Prozedur aufzurufen (eine Funktion, die kein sinnvolles Ergebnis zurückgibt; in Python geben Prozeduren den Wert None zurück). Andere Verwendungen von Ausdrucksanweisungen sind erlaubt und gelegentlich nützlich. Die Syntax für eine Ausdrucksanweisung lautet:

expression_stmt: starred_expression

Eine Ausdrucksanweisung wertet die Ausdrucksliste (die ein einzelner Ausdruck sein kann) aus.

Im interaktiven Modus wird der Wert, wenn er nicht None ist, mit der eingebauten Funktion repr() in einen String umgewandelt und der resultierende String wird auf einer eigenen Zeile auf die Standardausgabe geschrieben (außer wenn das Ergebnis None ist, damit Funktionsaufrufe keine Ausgabe verursachen).

7.2. Zuweisungsanweisungen

Zuweisungsanweisungen werden verwendet, um Namen (neu) an Werte zu binden und Attribute oder Elemente von veränderlichen Objekten zu modifizieren.

assignment_stmt: (target_list "=")+ (starred_expression | yield_expression)
target_list:     target ("," target)* [","]
target:          identifier
                 | "(" [target_list] ")"
                 | "[" [target_list] "]"
                 | attributeref
                 | subscription
                 | slicing
                 | "*" target

(Siehe Abschnitt Primaries für die Syntaxdefinitionen von attributeref, subscription und slicing.)

Eine Zuweisungsanweisung wertet die Ausdrucksliste aus (denken Sie daran, dass dies ein einzelner Ausdruck oder eine durch Kommas getrennte Liste sein kann, wobei letztere ein Tupel ergibt) und weist das einzelne resultierende Objekt von links nach rechts jedem der Ziel-Listen zu.

Die Zuweisung wird rekursiv definiert, abhängig von der Form des Ziels (Liste). Wenn ein Ziel Teil eines veränderlichen Objekts ist (eine Attributreferenz, ein Abonnement oder ein Slice), muss das veränderliche Objekt letztendlich die Zuweisung durchführen und über seine Gültigkeit entscheiden, und kann eine Ausnahme auslösen, wenn die Zuweisung inakzeptabel ist. Die von verschiedenen Typen beobachteten Regeln und die ausgelösten Ausnahmen sind in der Definition der Objekttypen aufgeführt (siehe Abschnitt Die Standard-Typenhierarchie).

Die Zuweisung eines Objekts an eine Ziel-Liste, optional in Klammern oder eckigen Klammern eingeschlossen, wird rekursiv wie folgt definiert.

  • Wenn die Ziel-Liste ein einzelnes Ziel ohne nachfolgendes Komma ist, optional in Klammern, wird das Objekt diesem Ziel zugewiesen.

  • Andernfalls

    • Wenn die Ziel-Liste ein Ziel enthält, dem ein Sternchen vorangestellt ist und das als „gestarntes“ Ziel bezeichnet wird: Das Objekt muss ein Iterable sein, das mindestens so viele Elemente enthält, wie es Ziele in der Ziel-Liste gibt, minus eins. Die ersten Elemente des Iterables werden von links nach rechts den Zielen vor dem gestarnten Ziel zugewiesen. Die letzten Elemente des Iterables werden den Zielen nach dem gestarnten Ziel zugewiesen. Eine Liste der verbleibenden Elemente im Iterable wird dann dem gestarnten Ziel zugewiesen (die Liste kann leer sein).

    • Andernfalls: Das Objekt muss ein Iterable mit der gleichen Anzahl von Elementen wie die Ziele in der Ziel-Liste sein, und die Elemente werden von links nach rechts den entsprechenden Zielen zugewiesen.

Die Zuweisung eines Objekts an ein einzelnes Ziel wird rekursiv wie folgt definiert.

  • Wenn das Ziel ein Bezeichner (Name) ist

    • Wenn der Name nicht in einer global oder nonlocal Anweisung im aktuellen Codeblock vorkommt: wird der Name an das Objekt im aktuellen lokalen Namensraum gebunden.

    • Andernfalls: wird der Name im globalen Namensraum oder im äußeren Namensraum, der durch nonlocal bestimmt wird, gebunden.

    Der Name wird neu gebunden, wenn er bereits gebunden war. Dies kann dazu führen, dass die Referenzanzahl des zuvor an den Namen gebundenen Objekts Null erreicht, wodurch das Objekt freigegeben und sein Destruktor (falls vorhanden) aufgerufen wird.

  • Wenn das Ziel eine Attributreferenz ist: Der primäre Ausdruck in der Referenz wird ausgewertet. Er sollte ein Objekt mit zuweisbaren Attributen liefern; wenn dies nicht der Fall ist, wird TypeError ausgelöst. Dieses Objekt wird dann aufgefordert, das zugewiesene Objekt dem angegebenen Attribut zuzuweisen; wenn es die Zuweisung nicht durchführen kann, löst es eine Ausnahme aus (normalerweise, aber nicht notwendigerweise AttributeError).

    Hinweis: Wenn das Objekt eine Klasseninstanz ist und die Attributreferenz auf beiden Seiten des Zuweisungsoperators vorkommt, kann der Ausdruck auf der rechten Seite, a.x, entweder ein Instanzattribut oder (wenn kein Instanzattribut existiert) ein Klassenattribut abrufen. Das Ziel auf der linken Seite a.x wird immer als Instanzattribut gesetzt, und wird bei Bedarf erstellt. Daher beziehen sich die beiden Vorkommen von a.x nicht unbedingt auf dasselbe Attribut: Wenn der Ausdruck auf der rechten Seite auf ein Klassenattribut verweist, erstellt die linke Seite ein neues Instanzattribut als Ziel der Zuweisung.

    class Cls:
    x = 3             # class variable
inst = Cls()
inst.x = inst.x + 1   # writes inst.x as 4 leaving Cls.x as 3

    Diese Beschreibung gilt nicht unbedingt für Deskriptor-Attribute, wie z.B. Eigenschaften, die mit property() erstellt wurden.

  • Wenn das Ziel eine Subskription ist: Der primäre Ausdruck in der Referenz wird ausgewertet. Er sollte entweder ein veränderliches Sequenzobjekt (wie eine Liste) oder ein Mapping-Objekt (wie ein Dictionary) liefern. Als nächstes wird der Subskriptionsausdruck ausgewertet.

    Wenn das Primäre ein veränderliches Sequenzobjekt (wie eine Liste) ist, muss die Subskription eine Ganzzahl liefern. Wenn sie negativ ist, wird die Länge der Sequenz zu ihr addiert. Der resultierende Wert muss eine nicht-negative Ganzzahl kleiner als die Länge der Sequenz sein, und die Sequenz wird aufgefordert, das zugewiesene Objekt seinem Element mit diesem Index zuzuweisen. Wenn der Index außerhalb des Bereichs liegt, wird IndexError ausgelöst (Zuweisung an eine subskribierte Sequenz kann keine neuen Elemente zu einer Liste hinzufügen).

    Wenn das Primäre ein Mapping-Objekt (wie ein Dictionary) ist, muss die Subskription einen Typ haben, der mit dem Schlüsseltyp des Mappings kompatibel ist, und das Mapping wird dann aufgefordert, ein Schlüssel/Wert-Paar zu erstellen, das die Subskription dem zugewiesenen Objekt zuordnet. Dies kann entweder ein vorhandenes Schlüssel/Wert-Paar mit demselben Schlüsselwert ersetzen oder ein neues Schlüssel/Wert-Paar einfügen (wenn kein Schlüssel mit demselben Wert existierte).

    Für benutzerdefinierte Objekte wird die Methode __setitem__() mit den entsprechenden Argumenten aufgerufen.

  • Wenn das Ziel ein Slicing ist: Der primäre Ausdruck in der Referenz wird ausgewertet. Er sollte ein veränderliches Sequenzobjekt (wie eine Liste) liefern. Das zugewiesene Objekt sollte ein Sequenzobjekt desselben Typs sein. Als nächstes werden die untere und obere Schranken-Ausdrücke ausgewertet, soweit sie vorhanden sind; Standardwerte sind Null und die Länge der Sequenz. Die Schranken sollten zu Ganzzahlen ausgewertet werden. Wenn eine der Schranken negativ ist, wird die Länge der Sequenz zu ihr addiert. Die resultierenden Schranken werden beschnitten, um zwischen Null und der Länge der Sequenz, einschließlich, zu liegen. Schließlich wird das Sequenzobjekt aufgefordert, das Slice durch die Elemente der zugewiesenen Sequenz zu ersetzen. Die Länge des Slices kann von der Länge der zugewiesenen Sequenz abweichen, wodurch die Länge der Zielsequenz verändert wird, wenn die Zielsequenz dies zulässt.

CPython-Implementierungsdetail: In der aktuellen Implementierung wird die Syntax für Ziele als dieselbe wie für Ausdrücke betrachtet, und ungültige Syntax wird während der Codeerzeugungsphase abgelehnt, was zu weniger detaillierten Fehlermeldungen führt.

Obwohl die Definition der Zuweisung impliziert, dass sich Überlappungen zwischen der linken und der rechten Seite „gleichzeitig“ ergeben (z. B. vertauscht a, b = b, a zwei Variablen), treten Überlappungen *innerhalb* der Sammlung der zugewiesenen Variablen von links nach rechts auf, was manchmal zu Verwirrung führt. Beispielsweise gibt das folgende Programm [0, 2] aus.

x = [0, 1]
i = 0
i, x[i] = 1, 2         # i is updated, then x[i] is updated
print(x)

Siehe auch

PEP 3132 – Erweiterte Iterable-Entpackung

Die Spezifikation für die *target Funktion.

7.2.1. Erweiterte Zuweisungsanweisungen

Erweiterte Zuweisung ist die Kombination einer binären Operation und einer Zuweisungsanweisung in einer einzigen Anweisung.

augmented_assignment_stmt: augtarget augop (expression_list | yield_expression)
augtarget:                 identifier | attributeref | subscription | slicing
augop:                     "+=" | "-=" | "*=" | "@=" | "/=" | "//=" | "%=" | "**="
                           | ">>=" | "<<=" | "&=" | "^=" | "|="

(Siehe Abschnitt Primaries für die Syntaxdefinitionen der letzten drei Symbole.)

Eine erweiterte Zuweisung wertet das Ziel (das im Gegensatz zu normalen Zuweisungsanweisungen keine Entpackung sein kann) und die Ausdrucksliste aus, führt die spezifische binäre Operation für den Zuweisungstyp auf den beiden Operanden aus und weist das Ergebnis dem ursprünglichen Ziel zu. Das Ziel wird nur einmal ausgewertet.

Eine erweiterte Zuweisungsanweisung wie x += 1 kann umgeschrieben werden als x = x + 1, um einen ähnlichen, aber nicht exakt gleichen Effekt zu erzielen. In der erweiterten Version wird x nur einmal ausgewertet. Außerdem wird, wenn möglich, die tatsächliche Operation *in-place* durchgeführt, d.h. anstatt ein neues Objekt zu erstellen und dieses dem Ziel zuzuweisen, wird das alte Objekt modifiziert.

Im Gegensatz zu normalen Zuweisungen wertet erweiterte Zuweisungen die linke Seite *vor* der Auswertung der rechten Seite aus. Zum Beispiel wird bei a[i] += f(x) zuerst a[i] nachgeschlagen, dann f(x) ausgewertet und die Addition durchgeführt, und zuletzt das Ergebnis zurück nach a[i] geschrieben.

Mit Ausnahme der Zuweisung an Tupel und mehrerer Ziele in einer einzigen Anweisung wird die Zuweisung durch erweiterte Zuweisungsanweisungen auf dieselbe Weise behandelt wie normale Zuweisungen. Ebenso, mit Ausnahme des möglichen *in-place*-Verhaltens, ist die von der erweiterten Zuweisung durchgeführte binäre Operation dieselbe wie die normalen binären Operationen.

Für Ziele, die Attributreferenzen sind, gilt die gleiche Warnung bezüglich Klassen- und Instanzattributen wie bei regulären Zuweisungen.

7.2.2. Annotierte Zuweisungsanweisungen

Annotation-Zuweisung ist die Kombination einer Variablen- oder Attributannotation und einer optionalen Zuweisungsanweisung in einer einzigen Anweisung.

annotated_assignment_stmt: augtarget ":" expression
                           ["=" (starred_expression | yield_expression)]

Der Unterschied zu normalen Zuweisungsanweisungen besteht darin, dass nur ein einzelnes Ziel erlaubt ist.

Das Zuweisungsziel wird als „einfach“ betrachtet, wenn es aus einem einzelnen Namen besteht, der nicht in Klammern eingeschlossen ist. Bei einfachen Zuweisungszielen, wenn sie im Klassen- oder Modul-Scope sind, werden die Annotationen in einem latent ausgewerteten Annotation-Scope gesammelt. Die Annotationen können über das Attribut __annotations__ einer Klasse oder eines Moduls oder über die Einrichtungen im Modul annotationlib ausgewertet werden.

Wenn das Zuweisungsziel nicht einfach ist (ein Attribut, ein Subskriptionsknoten oder ein Name in Klammern), wird die Annotation niemals ausgewertet.

Wenn ein Name in einem Funktions-Scope annotiert wird, dann ist dieser Name für diesen Scope lokal. Annotationen werden niemals ausgewertet und in Funktions-Scopes gespeichert.

Wenn die rechte Seite vorhanden ist, führt eine annotierte Zuweisung die tatsächliche Zuweisung durch, als ob keine Annotation vorhanden wäre. Wenn die rechte Seite für ein Ausdrucksziel nicht vorhanden ist, wertet der Interpreter das Ziel aus, mit Ausnahme des letzten Aufrufs von __setitem__() oder __setattr__().

Siehe auch

PEP 526 – Syntax für Variablenannotationen

Der Vorschlag, der die Syntax für die Annotation von Variablentypen (einschließlich Klassenvariablen und Instanzvariablen) hinzufügte, anstatt sie durch Kommentare auszudrücken.

PEP 484 – Typ-Hints

Der Vorschlag, der das Modul typing hinzufügte, um eine Standard-Syntax für Typannotationen bereitzustellen, die in statischen Analysewerkzeugen und IDEs verwendet werden kann.

Geändert in Version 3.8: Annotierte Zuweisungen erlauben nun dieselben Ausdrücke auf der rechten Seite wie reguläre Zuweisungen. Zuvor verursachten einige Ausdrücke (wie nicht-klammerige Tupelausdrücke) einen Syntaxfehler.

Geändert in Version 3.14: Annotationen werden nun in einem separaten Annotation-Scope latent ausgewertet. Wenn das Zuweisungsziel nicht einfach ist, werden Annotationen niemals ausgewertet.

7.3. Die assert Anweisung

Assert-Anweisungen sind eine bequeme Möglichkeit, Debugging-Assertions in ein Programm einzufügen.

assert_stmt: "assert" expression ["," expression]

Die einfache Form, assert expression, ist äquivalent zu

if __debug__:
    if not expression: raise AssertionError

Die erweiterte Form, assert expression1, expression2, ist äquivalent zu

if __debug__:
    if not expression1: raise AssertionError(expression2)

Diese Äquivalenzen gehen davon aus, dass __debug__ und AssertionError sich auf die eingebauten Variablen mit diesen Namen beziehen. In der aktuellen Implementierung ist die eingebaute Variable __debug__ unter normalen Umständen True, und False, wenn Optimierung angefordert wird (Kommandozeilenoption -O). Der aktuelle Code-Generator gibt keinen Code für eine assert-Anweisung aus, wenn zur Kompilierzeit eine Optimierung angefordert wird. Beachten Sie, dass es nicht notwendig ist, den Quellcode des fehlgeschlagenen Ausdrucks in die Fehlermeldung aufzunehmen; er wird als Teil des Stack-Trace angezeigt.

Zuweisungen an __debug__ sind illegal. Der Wert der eingebauten Variablen wird beim Start des Interpreters bestimmt.

7.4. Die pass Anweisung

pass_stmt: "pass"

pass ist eine Nulloperation – wenn sie ausgeführt wird, passiert nichts. Sie ist nützlich als Platzhalter, wenn syntaktisch eine Anweisung erforderlich ist, aber kein Code ausgeführt werden muss, zum Beispiel:

def f(arg): pass    # a function that does nothing (yet)

class C: pass       # a class with no methods (yet)

7.5. Die del Anweisung

del_stmt: "del" target_list

Löschen wird rekursiv sehr ähnlich zur Definition von Zuweisung definiert. Anstatt es im Detail auszuführen, hier einige Hinweise.

Das Löschen einer Ziel-Liste löscht rekursiv jedes Ziel von links nach rechts.

Das Löschen eines Namens entfernt die Bindung dieses Namens aus dem lokalen oder globalen Namensraum, abhängig davon, ob der Name in einer global Anweisung im selben Codeblock vorkommt. Der Versuch, einen ungebundenen Namen zu löschen, löst eine NameError Ausnahme aus.

Das Löschen von Attributreferenzen, Subskriptionen und Slicings wird an das beteiligte primäre Objekt übergeben; das Löschen eines Slicings ist im Allgemeinen äquivalent zur Zuweisung eines leeren Slices des richtigen Typs (aber selbst dies wird vom geslicten Objekt bestimmt).

Geändert in Version 3.2: Zuvor war es illegal, einen Namen aus dem lokalen Namensraum zu löschen, wenn er als freie Variable in einem verschachtelten Block vorkam.

7.6. Die return Anweisung

return_stmt: "return" [expression_list]

return darf nur syntaktisch verschachtelt in einer Funktionsdefinition vorkommen, nicht in einer verschachtelten Klassendefinition.

Wenn eine Ausdrucksliste vorhanden ist, wird sie ausgewertet, andernfalls wird None eingesetzt.

return verlässt den aktuellen Funktionsaufruf mit der Ausdrucksliste (oder None) als Rückgabewert.

Wenn return die Kontrolle aus einer try-Anweisung mit einer finally-Klausel übergibt, wird diese finally-Klausel ausgeführt, bevor die Funktion tatsächlich verlassen wird.

In einer Generatorfunktion zeigt die return-Anweisung an, dass der Generator beendet ist, und löst StopIteration aus. Der zurückgegebene Wert (falls vorhanden) wird zur Konstruktion von StopIteration verwendet und wird zum Attribut StopIteration.value.

In einer asynchronen Generatorfunktion zeigt eine leere return-Anweisung an, dass der asynchrone Generator beendet ist, und löst StopAsyncIteration aus. Eine nicht-leere return-Anweisung ist eine Syntaxfehler in einer asynchronen Generatorfunktion.

7.7. Die yield Anweisung

yield_stmt: yield_expression

Eine yield-Anweisung ist semantisch äquivalent zu einem yield-Ausdruck. Die yield-Anweisung kann verwendet werden, um die Klammern wegzulassen, die sonst in der äquivalenten yield-Ausdrucksanweisung erforderlich wären. Zum Beispiel die yield-Anweisungen:

yield <expr>
yield from <expr>

sind äquivalent zu den yield-Ausdrucksanweisungen:

(yield <expr>)
(yield from <expr>)

Yield-Ausdrücke und -Anweisungen werden nur bei der Definition einer Generatorfunktion verwendet und nur im Körper der Generatorfunktion. Die Verwendung von yield in einer Funktionsdefinition reicht aus, um diese Definition zu veranlassen, eine Generatorfunktion anstelle einer normalen Funktion zu erstellen.

Für vollständige Details zu yield-Semantik siehe Abschnitt Yield-Ausdrücke.

7.8. Die raise Anweisung

raise_stmt: "raise" [expression ["from" expression]]

Wenn keine Ausdrücke vorhanden sind, re-wirft raise die Ausnahme, die gerade behandelt wird, was auch als die *aktive Ausnahme* bezeichnet wird. Wenn derzeit keine aktive Ausnahme vorhanden ist, wird eine RuntimeError-Ausnahme ausgelöst, die besagt, dass dies ein Fehler ist.

Andernfalls wertet raise den ersten Ausdruck als Ausnahmeobjekt aus. Es muss entweder eine Unterklasse oder eine Instanz von BaseException sein. Wenn es sich um eine Klasse handelt, wird die Ausnahmeinstanz bei Bedarf durch Instanziierung der Klasse ohne Argumente erzeugt.

Der *Typ* der Ausnahme ist die Klasse der Ausnahmeinstanz, der *Wert* ist die Instanz selbst.

Ein Traceback-Objekt wird normalerweise automatisch erstellt, wenn eine Ausnahme ausgelöst wird, und als Attribut __traceback__ angehängt. Sie können eine Ausnahme erstellen und Ihren eigenen Traceback in einem Schritt mit der Ausnahme-Methode with_traceback() (die dieselbe Ausnahmeinstanz zurückgibt, mit ihrem Traceback auf ihr Argument gesetzt) festlegen, wie hier:

raise Exception("foo occurred").with_traceback(tracebackobj)

Die from-Klausel wird für die Ausnahmeverkettung verwendet: wenn gegeben, muss der zweite *Ausdruck* eine weitere Ausnahmeklasse oder -instanz sein. Wenn der zweite Ausdruck eine Ausnahmeinstanz ist, wird sie als __cause__-Attribut (das beschreibbar ist) an die ausgelöste Ausnahme angehängt. Wenn der Ausdruck eine Ausnahme-Klasse ist, wird die Klasse instanziiert und die resultierende Ausnahmeinstanz wird als __cause__-Attribut an die ausgelöste Ausnahme angehängt. Wenn die ausgelöste Ausnahme nicht behandelt wird, werden beide Ausnahmen gedruckt.

>>> try:
...     print(1 / 0)
... except Exception as exc:
...     raise RuntimeError("Something bad happened") from exc
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
    print(1 / 0)
          ~~^~~
ZeroDivisionError: division by zero

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
    raise RuntimeError("Something bad happened") from exc
RuntimeError: Something bad happened

Ein ähnlicher Mechanismus funktioniert implizit, wenn eine neue Ausnahme ausgelöst wird, während eine Ausnahme bereits behandelt wird. Eine Ausnahme kann behandelt werden, wenn eine except- oder finally-Klausel oder eine with-Anweisung verwendet wird. Die vorherige Ausnahme wird dann als __context__-Attribut der neuen Ausnahme angehängt.

>>> try:
...     print(1 / 0)
... except:
...     raise RuntimeError("Something bad happened")
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
    print(1 / 0)
          ~~^~~
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
    raise RuntimeError("Something bad happened")
RuntimeError: Something bad happened

Die Ausnahmeverkettung kann explizit unterdrückt werden, indem None in der from-Klausel angegeben wird.

>>> try:
...     print(1 / 0)
... except:
...     raise RuntimeError("Something bad happened") from None
...
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
RuntimeError: Something bad happened

Weitere Informationen zu Ausnahmen finden Sie in Abschnitt Ausnahmen, und Informationen zur Behandlung von Ausnahmen finden Sie in Abschnitt Die try-Anweisung.

Geändert in Version 3.3: None ist nun als Y in raise X from Y zulässig.

Das Attribut __suppress_context__ wurde hinzugefügt, um die automatische Anzeige des Ausnahme-Kontextes zu unterdrücken.

Geändert in Version 3.11: Wenn der Traceback der aktiven Ausnahme in einer except-Klausel modifiziert wird, re-wirft eine nachfolgende raise-Anweisung die Ausnahme mit dem modifizierten Traceback. Zuvor wurde die Ausnahme mit dem Traceback neu ausgelöst, den sie beim Erfassen hatte.

7.9. Die break Anweisung

break_stmt: "break"

break darf nur syntaktisch verschachtelt in einer for- oder while-Schleife vorkommen, aber nicht verschachtelt in einer Funktions- oder Klassendefinition innerhalb dieser Schleife.

Es beendet die nächstgelegene umschließende Schleife und überspringt die optionale else-Klausel, falls die Schleife eine solche hat.

Wenn eine for-Schleife durch break beendet wird, behält das Schleifensteuerungsziel seinen aktuellen Wert.

Wenn break die Kontrolle aus einer try-Anweisung mit einer finally-Klausel übergibt, wird diese finally-Klausel ausgeführt, bevor die Schleife tatsächlich verlassen wird.

7.10. Die continue Anweisung

continue_stmt: "continue"

continue darf nur syntaktisch verschachtelt in einer for- oder while-Schleife vorkommen, aber nicht verschachtelt in einer Funktions- oder Klassendefinition innerhalb dieser Schleife. Sie fährt mit dem nächsten Durchlauf der nächstgelegenen umschließenden Schleife fort.

Wenn continue die Kontrolle aus einer try-Anweisung mit einer finally-Klausel ausgibt, wird diese finally-Klausel ausgeführt, bevor der nächste Schleifendurchlauf beginnt.

7.11. Die import-Anweisung

import_stmt:     "import" module ["as" identifier] ("," module ["as" identifier])*
                 | "from" relative_module "import" identifier ["as" identifier]
                 ("," identifier ["as" identifier])*
                 | "from" relative_module "import" "(" identifier ["as" identifier]
                 ("," identifier ["as" identifier])* [","] ")"
                 | "from" relative_module "import" "*"
module:          (identifier ".")* identifier
relative_module: "."* module | "."+

Die grundlegende import-Anweisung (ohne from-Klausel) wird in zwei Schritten ausgeführt:

  1. ein Modul finden, es gegebenenfalls laden und initialisieren

  2. einen oder mehrere Namen im lokalen Namensraum für den Gültigkeitsbereich definieren, in dem die import-Anweisung auftritt.

Wenn die Anweisung mehrere Klauseln enthält (durch Kommas getrennt), werden die beiden Schritte für jede Klausel separat durchgeführt, so als ob die Klauseln in einzelne import-Anweisungen aufgeteilt worden wären.

Die Details des ersten Schritts, das Finden und Laden von Modulen, werden im Abschnitt über das Importsystem detaillierter beschrieben, der auch die verschiedenen Arten von Paketen und Modulen beschreibt, die importiert werden können, sowie alle Hooks, die zur Anpassung des Importsystems verwendet werden können. Beachten Sie, dass Fehler in diesem Schritt entweder darauf hindeuten können, dass das Modul nicht gefunden werden konnte, *oder* dass während der Initialisierung des Moduls ein Fehler aufgetreten ist, was die Ausführung des Modulcodes einschließt.

Wenn das angeforderte Modul erfolgreich abgerufen wurde, wird es auf eine von drei Arten im lokalen Namensraum verfügbar gemacht:

  • Wenn auf den Modulnamen as folgt, wird der Name nach as direkt an das importierte Modul gebunden.

  • Wenn kein anderer Name angegeben ist und das importierte Modul ein Top-Level-Modul ist, wird der Name des Moduls im lokalen Namensraum als Referenz auf das importierte Modul gebunden.

  • Wenn das importierte Modul *kein* Top-Level-Modul ist, wird der Name des Top-Level-Pakets, das das Modul enthält, im lokalen Namensraum als Referenz auf das Top-Level-Paket gebunden. Das importierte Modul muss über seinen vollständigen qualifizierten Namen anstelle des direkten Zugriffs angesprochen werden.

Die from-Form verwendet einen etwas komplexeren Prozess:

  1. das in der from-Klausel angegebene Modul finden, es gegebenenfalls laden und initialisieren;

  2. für jede der in den import-Klauseln angegebenen Bezeichner:

    1. prüfen, ob das importierte Modul ein Attribut mit diesem Namen hat;

    2. andernfalls versuchen, ein Untermodul mit diesem Namen zu importieren und dann das importierte Modul erneut auf dieses Attribut prüfen;

    3. wenn das Attribut nicht gefunden wird, wird ein ImportError ausgelöst.

    4. andernfalls wird eine Referenz auf diesen Wert im lokalen Namensraum gespeichert, wobei der Name in der as-Klausel verwendet wird, falls vorhanden, andernfalls der Attributname.

Beispiele

import foo                 # foo imported and bound locally
import foo.bar.baz         # foo, foo.bar, and foo.bar.baz imported, foo bound locally
import foo.bar.baz as fbb  # foo, foo.bar, and foo.bar.baz imported, foo.bar.baz bound as fbb
from foo.bar import baz    # foo, foo.bar, and foo.bar.baz imported, foo.bar.baz bound as baz
from foo import attr       # foo imported and foo.attr bound as attr

Wenn die Liste der Bezeichner durch einen Stern ('*') ersetzt wird, werden alle öffentlichen Namen, die im Modul definiert sind, im lokalen Namensraum für den Gültigkeitsbereich gebunden, in dem die import-Anweisung auftritt.

Die von einem Modul definierten *öffentlichen Namen* werden ermittelt, indem der Namensraum des Moduls auf eine Variable namens __all__ geprüft wird; wenn diese definiert ist, muss es sich um eine Sequenz von Zeichenketten handeln, die Namen sind, die von diesem Modul definiert oder importiert wurden. Die in __all__ angegebenen Namen gelten alle als öffentlich und müssen vorhanden sein. Wenn __all__ nicht definiert ist, umfasst die Menge der öffentlichen Namen alle Namen, die im Namensraum des Moduls gefunden werden und nicht mit einem Unterstrichzeichen ('_') beginnen. __all__ sollte die gesamte öffentliche API enthalten. Es soll verhindern, dass versehentlich Elemente exportiert werden, die nicht Teil der API sind (wie z. B. Bibliotheksmodule, die im Modul importiert und verwendet wurden).

Die Wildcard-Form des Imports — from module import * — ist nur auf Modulebene zulässig. Der Versuch, sie in Klassen- oder Funktionsdefinitionen zu verwenden, löst einen SyntaxError aus.

Wenn Sie angeben, welches Modul importiert werden soll, müssen Sie nicht den absoluten Namen des Moduls angeben. Wenn ein Modul oder Paket in einem anderen Paket enthalten ist, ist es möglich, einen relativen Import innerhalb desselben Top-Pakets durchzuführen, ohne den Paketnamen zu nennen. Durch die Verwendung führender Punkte in dem nach from angegebenen Modul oder Paket können Sie angeben, wie hoch Sie die aktuelle Paket-Hierarchie durchlaufen möchten, ohne exakte Namen anzugeben. Ein führender Punkt bedeutet das aktuelle Paket, in dem sich das Modul befindet, das den Import durchführt. Zwei Punkte bedeuten eine Ebene höher. Drei Punkte sind zwei Ebenen höher usw. Wenn Sie also from . import mod aus einem Modul im Paket pkg ausführen, importieren Sie letztendlich pkg.mod. Wenn Sie from ..subpkg2 import mod aus pkg.subpkg1 ausführen, importieren Sie pkg.subpkg2.mod. Die Spezifikation für relative Imports ist im Abschnitt Relative Paketimporte enthalten.

importlib.import_module() wird bereitgestellt, um Anwendungen zu unterstützen, die die zu ladenden Module dynamisch bestimmen.

Löst ein Audit-Event import mit den Argumenten module, filename, sys.path, sys.meta_path, sys.path_hooks aus.

7.11.1. Future-Anweisungen

Eine Future-Anweisung ist eine Direktive für den Compiler, dass ein bestimmtes Modul mit Syntax oder Semantik kompiliert werden soll, die in einer bestimmten zukünftigen Version von Python verfügbar sein werden, in der das Feature zum Standard wird.

Die Future-Anweisung soll die Migration zu zukünftigen Versionen von Python erleichtern, die inkompatible Änderungen an der Sprache einführen. Sie ermöglicht die Verwendung der neuen Features pro Modul vor der Veröffentlichung, in der das Feature zum Standard wird.

future_stmt: "from" "__future__" "import" feature ["as" identifier]
             ("," feature ["as" identifier])*
             | "from" "__future__" "import" "(" feature ["as" identifier]
             ("," feature ["as" identifier])* [","] ")"
feature:     identifier

Eine Future-Anweisung muss am Anfang des Moduls erscheinen. Die einzigen Zeilen, die vor einer Future-Anweisung stehen dürfen, sind:

  • der Modul-Docstring (falls vorhanden),

  • Kommentare,

  • Leerzeilen und

  • andere Future-Anweisungen.

Das einzige Feature, das die Verwendung der Future-Anweisung erfordert, sind annotations (siehe PEP 563).

Alle historischen Features, die durch die Future-Anweisung aktiviert werden, werden von Python 3 immer noch erkannt. Die Liste umfasst absolute_import, division, generators, generator_stop, unicode_literals, print_function, nested_scopes und with_statement. Sie sind alle redundant, da sie immer aktiviert sind, und werden nur aus Gründen der Abwärtskompatibilität beibehalten.

Eine Future-Anweisung wird zur Kompilierzeit erkannt und speziell behandelt: Änderungen an der Semantik von Kernkonstrukten werden oft durch Generierung von anderem Code implementiert. Es kann sogar der Fall sein, dass ein neues Feature neue inkompatible Syntax einführt (wie z. B. ein neues reserviertes Wort), in diesem Fall muss der Compiler das Modul möglicherweise anders parsen. Solche Entscheidungen können nicht auf die Laufzeit verschoben werden.

Für jede bestimmte Version kennt der Compiler die definierten Feature-Namen und löst einen Kompilierzeitfehler aus, wenn eine Future-Anweisung ein ihm unbekanntes Feature enthält.

Die direkte Laufzeitsemantik ist die gleiche wie bei jeder Importanweisung: Es gibt ein Standardmodul __future__, das später beschrieben wird, und es wird auf übliche Weise zur Zeit der Ausführung der Future-Anweisung importiert.

Die interessanten Laufzeitsemantiken hängen vom spezifischen Feature ab, das durch die Future-Anweisung aktiviert wird.

Beachten Sie, dass an der Anweisung nichts Besonderes ist

import __future__ [as name]

Dies ist keine Future-Anweisung; es ist eine gewöhnliche Importanweisung ohne besondere Semantik oder Syntaxbeschränkungen.

Code, der durch Aufrufe der integrierten Funktionen exec() und compile() kompiliert wird, die in einem Modul M auftreten, das eine Future-Anweisung enthält, verwendet standardmäßig die neuen Syntax oder Semantik, die mit der Future-Anweisung verbunden sind. Dies kann durch optionale Argumente an compile() gesteuert werden – siehe Dokumentation dieser Funktion für Details.

Eine Future-Anweisung, die an einer interaktiven Interpreter-Eingabeaufforderung eingegeben wird, wird für den Rest der Interpreter-Sitzung wirksam. Wenn ein Interpreter mit der Option -i gestartet wird, ihm ein Skriptname zur Ausführung übergeben wird und das Skript eine Future-Anweisung enthält, ist diese in der interaktiven Sitzung wirksam, die nach der Ausführung des Skripts gestartet wird.

Siehe auch

PEP 236 - Zurück zu __future__

Der ursprüngliche Vorschlag für den __future__-Mechanismus.

7.12. Die global-Anweisung

global_stmt: "global" identifier ("," identifier)*

Die global-Anweisung bewirkt, dass die aufgeführten Bezeichner als global interpretiert werden. Es wäre unmöglich, einer globalen Variablen ohne global einen Wert zuzuweisen, obwohl freie Variablen auf Globals verweisen dürfen, ohne als global deklariert zu werden.

Die global-Anweisung gilt für den gesamten aktuellen Gültigkeitsbereich (Modul, Funktionskörper oder Klassendefinition). Ein SyntaxError wird ausgelöst, wenn eine Variable vor ihrer globalen Deklaration im Gültigkeitsbereich verwendet oder zugewiesen wird.

Auf Modulebene sind alle Variablen global, daher hat eine global-Anweisung keine Auswirkung. Variablen dürfen jedoch immer noch nicht vor ihrer global-Deklaration verwendet oder zugewiesen werden. Diese Anforderung ist in der interaktiven Eingabeaufforderung (REPL) gelockert.

Hinweis für Programmierer: global ist eine Direktive für den Parser. Sie gilt nur für Code, der gleichzeitig mit der global-Anweisung geparst wird. Insbesondere hat eine global-Anweisung, die in einem String oder Code-Objekt enthalten ist, das der integrierten Funktion exec() übergeben wird, keine Auswirkung auf den Code-Block, der den Funktionsaufruf *enthält*, und der Code in einem solchen String wird von global-Anweisungen im Code, der den Funktionsaufruf enthält, nicht beeinflusst. Das Gleiche gilt für die Funktionen eval() und compile().

7.13. Die nonlocal-Anweisung

nonlocal_stmt: "nonlocal" identifier ("," identifier)*

Wenn die Definition einer Funktion oder Klasse verschachtelt (eingeschlossen) innerhalb der Definitionen anderer Funktionen ist, sind ihre nichtlokalen Gültigkeitsbereiche die lokalen Gültigkeitsbereiche der umschließenden Funktionen. Die nonlocal-Anweisung bewirkt, dass die aufgeführten Bezeichner auf Namen verweisen, die zuvor in nichtlokalen Gültigkeitsbereichen gebunden wurden. Sie ermöglicht es gekapseltem Code, solche nichtlokalen Bezeichner neu zu binden. Wenn ein Name in mehreren nichtlokalen Gültigkeitsbereichen gebunden ist, wird die nächste Bindung verwendet. Wenn ein Name in keinem nichtlokalen Gültigkeitsbereich gebunden ist oder kein nichtlokaler Gültigkeitsbereich vorhanden ist, wird ein SyntaxError ausgelöst.

Die nonlocal-Anweisung gilt für den gesamten Gültigkeitsbereich eines Funktions- oder Klassenkörpers. Ein SyntaxError wird ausgelöst, wenn eine Variable vor ihrer nichtlokalen Deklaration im Gültigkeitsbereich verwendet oder zugewiesen wird.

Siehe auch

PEP 3104 - Zugriff auf Namen in äußeren Gültigkeitsbereichen

Die Spezifikation für die nonlocal-Anweisung.

Hinweis für Programmierer: nonlocal ist eine Direktive für den Parser und gilt nur für Code, der zusammen mit ihm geparst wird. Siehe die Notiz zur global-Anweisung.

7.14. Die type-Anweisung

type_stmt: 'type' identifier [type_params] "=" expression

Die type-Anweisung deklariert einen Typ-Alias, der eine Instanz von typing.TypeAliasType ist.

Zum Beispiel erstellt die folgende Anweisung einen Typ-Alias:

type Point = tuple[float, float]

Dieser Code ist ungefähr äquivalent zu:

annotation-def VALUE_OF_Point():
    return tuple[float, float]
Point = typing.TypeAliasType("Point", VALUE_OF_Point())

annotation-def kennzeichnet einen Annotation-Scope, der sich meist wie eine Funktion verhält, jedoch mit einigen kleinen Unterschieden.

Der Wert des Typ-Alias wird im Annotation-Scope ausgewertet. Er wird nicht ausgewertet, wenn der Typ-Alias erstellt wird, sondern erst, wenn auf den Wert über das Attribut __value__ des Typ-Alias zugegriffen wird (siehe Lazy Evaluation). Dies ermöglicht es dem Typ-Alias, auf Namen zu verweisen, die noch nicht definiert sind.

Typ-Aliase können generisch gemacht werden, indem eine Typ-Parameterliste nach dem Namen hinzugefügt wird. Weitere Informationen finden Sie unter Generische Typ-Aliase.

type ist ein Soft Keyword.

Hinzugefügt in Version 3.12.

Siehe auch

PEP 695 - Typ-Parameter-Syntax

Einführung der type-Anweisung und der Syntax für generische Klassen und Funktionen.