6. Ausdrücke
************

In diesem Kapitel wird die Bedeutung der Elemente von Ausdrücken in
Python erläutert.

**Syntax Notes:** In this and the following chapters, extended BNF
notation will be used to describe syntax, not lexical analysis.  When
(one alternative of) a syntax rule has the form

   name ::= othername

und es wird keine Semantik angegeben, entspricht die Semantik dieser
Form von  "name" der von  "othername" .


6.1. Arithmetische Umrechnungen
===============================

When a description of an arithmetic operator below uses the phrase
"the numeric arguments are converted to a common type", this means
that the operator implementation for built-in types works as follows:

* If either argument is a complex number, the other is converted to
  complex;

* otherwise, if either argument is a floating-point number, the other
  is converted to floating point;

* otherwise, both must be integers and no conversion is necessary.

Some additional rules apply for certain operators (e.g., a string as a
left argument to the '%' operator).  Extensions must define their own
conversion behavior.


6.2. Atoms
==========

Atoms are the most basic elements of expressions.  The simplest atoms
are identifiers or literals.  Forms enclosed in parentheses, brackets
or braces are also categorized syntactically as atoms.  The syntax for
atoms is:

   atom      ::= identifier | literal | enclosure
   enclosure ::= parenth_form | list_display | dict_display | set_display
                 | generator_expression | yield_atom


6.2.1. Bezeichner (Namen)
-------------------------

Ein Bezeichner, der als Atom auftritt, ist ein Name. Die lexikalische
Definition finden Sie im Abschnitt  Identifiers and keywords , die
Dokumentation zu Benennung und Bindung im Abschnitt  Benennung und
Zuordnung .

Wenn der Name an ein Objekt gebunden ist, liefert die Auswertung des
Atoms dieses Objekt. Ist ein Name nicht gebunden, löst der Versuch,
ihn auszuwerten, eine  "NameError" -Ausnahme aus.


6.2.1.1. Private Namensumformung
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Wenn ein Bezeichner, der wörtlich in einer Klassendefinition vorkommt,
mit zwei oder mehr Unterstrichen beginnt und nicht mit zwei oder mehr
Unterstrichen endet, gilt er als *privater Name* dieser Klasse.

Siehe auch: Die Klassenspezifikationen.

Genauer gesagt werden private Namen in eine längere Form umgewandelt,
bevor Code für sie generiert wird. Ist der umgewandelte Name länger
als 255 Zeichen, kann es zu einer implementierungsabhängigen Kürzung
kommen.

Die Umformung ist unabhängig vom syntaktischen Kontext, in dem der
Bezeichner verwendet wird, jedoch werden nur die folgenden privaten
Bezeichner umgestaltet:

* Jeder Name, der als Name einer Variablen verwendet wird, die
  zugewiesen oder ausgelesen wird, sowie jeder Name eines Attributs,
  auf das zugegriffen wird.

  Das Attribut  "__name__"  von verschachtelten Funktionen, Klassen
  und Typaliasen wird jedoch nicht umbenannt.

* Der Name importierter Module, z. B.  "__spam"  in "import __spam" .
  Wenn das Modul Teil eines Pakets ist (d. h., sein Name enthält einen
  Punkt), wird der Name *nicht* umgewandelt, z. B. wird  "__foo"  in
  "import __foo.bar"  nicht umgewandelt.

* Der Name eines importierten Mitglieds, z. B.  "__f"  in  "from spam
  import __f" .

Die Transformationsregel ist wie folgt definiert:

* Der Klassenname, bei dem führende Unterstriche entfernt und ein
  einzelner führender Unterstrich eingefügt wurde, wird vor den
  Bezeichner gesetzt; so wird beispielsweise der Bezeichner  "__spam"
  , der in einer Klasse namens  "Foo" ,  "_Foo"  oder  "__Foo"
  vorkommt, in  "_Foo__spam"  umgewandelt.

* Wenn der Klassenname ausschließlich aus Unterstrichen besteht,
  erfolgt keine Umwandlung; der Bezeichner  "__spam" , der
  beispielsweise in einer Klasse namens  "_"  oder  "__"  vorkommt,
  bleibt unverändert.


6.2.2. Literale
---------------

Python supports string and bytes literals and various numeric
literals:

   literal ::= stringliteral | bytesliteral
               | integer | floatnumber | imagnumber

Evaluation of a literal yields an object of the given type (string,
bytes, integer, floating-point number, complex number) with the given
value.  The value may be approximated in the case of floating-point
and imaginary (complex) literals.  See section Literale for details.

Alle Literale entsprechen unveränderlichen Datentypen, weshalb die
Identität des Objekts weniger wichtig ist als sein Wert. Bei
mehrfacher Auswertung von Literalen mit demselben Wert (entweder an
derselben Stelle im Programmtext oder an einer anderen Stelle) kann
entweder dasselbe Objekt oder ein anderes Objekt mit demselben Wert
resultieren.


6.2.3. Formen in Klammern
-------------------------

Eine in Klammern gesetzte Form ist eine optionale Ausdrucksliste, die
in Klammern eingeschlossen ist:

   parenth_form ::= "(" [starred_expression] ")"

Eine in Klammern gesetzte Ausdrucksliste liefert das, was diese
Ausdrucksliste liefert: Enthält die Liste mindestens ein Komma,
liefert sie ein Tupel; andernfalls liefert sie den einzelnen Ausdruck,
aus dem die Ausdrucksliste besteht.

Ein leeres Klammerpaar ergibt ein leeres Tupel-Objekt. Da Tupel
unveränderlich sind, gelten dieselben Regeln wie für Literale (d. h.,
zwei Vorkommen des leeren Tupels ergeben möglicherweise dasselbe
Objekt, möglicherweise aber auch nicht).

Beachten Sie, dass Tupel nicht durch Klammern gebildet werden, sondern
durch die Verwendung von Kommas. Die Ausnahme bildet das leere Tupel,
für das Klammern *erforderlich* sind – würde man in Ausdrücken ein
"Nichts“ ohne Klammern zulassen, würde dies zu Mehrdeutigkeiten führen
und dazu, dass häufige Tippfehler unentdeckt bleiben.


6.2.4. Darstellungen für Listen, Mengen und Wörterbücher
--------------------------------------------------------

Zum Erstellen einer Liste, einer Menge oder eines Wörterbuchs bietet
Python spezielle Syntaxelemente, die als "displays“ bezeichnet werden
und jeweils in zwei Varianten vorliegen:

* entweder wird der Inhalt des Containers ausdrücklich aufgeführt,
  oder

* Sie werden mithilfe einer Reihe von Schleifen- und Filteranweisungen
  berechnet, die als *comprehension* bezeichnet werden.

Zu den gängigen Syntaxelementen für Komprimierungen gehören:

   comprehension ::= assignment_expression comp_for
   comp_for      ::= ["async"] "for" target_list "in" or_test [comp_iter]
   comp_iter     ::= comp_for | comp_if
   comp_if       ::= "if" or_test [comp_iter]

Die Ausdrucksform besteht aus einem einzelnen Ausdruck, gefolgt von
mindestens einer Klausel vom Typ  "for"  und null oder mehreren
Klauseln vom Typ  "for"  oder "if" . In diesem Fall sind die Elemente
des neuen Containers diejenigen, die entstehen würden, wenn man jede
der Klauseln vom Typ "for"  oder  "if"  als Block betrachtet, diese
von links nach rechts verschachtelt und den Ausdruck auswertet, um
jedes Mal, wenn der innerste Block erreicht wird, ein Element zu
erzeugen.

Abgesehen von dem iterierbaren Ausdruck in der ganz links stehenden
"for" -Klausel wird die Comprehension jedoch in einem separaten,
implizit verschachtelten Gültigkeitsbereich ausgeführt. Dadurch wird
sichergestellt, dass Namen, die in der Zielliste zugewiesen werden,
nicht in den übergeordneten Gültigkeitsbereich "überlaufen“.

Der iterierbare Ausdruck in der ganz links stehenden Klausel  "for"
wird direkt im umgebenden Gültigkeitsbereich ausgewertet und
anschließend als Argument an den implizit verschachtelten
Gültigkeitsbereich übergeben. Nachfolgende Klauseln  "for"  sowie
etwaige Filterbedingungen in der ganz links stehenden Klausel  "for"
können nicht im umgebenden Gültigkeitsbereich ausgewertet werden, da
sie möglicherweise von den Werten abhängen, die aus dem ganz links
stehenden iterierbaren Ausdruck stammen. Beispiel: "[x*y for x in
range(10) for y in range(x, x+10)]".

Um sicherzustellen, dass das Ergebnis der Auswertung stets ein
Container des entsprechenden Typs ist, sind Ausdrücke wie  "yield"
und  "yield from"  im implizit verschachtelten Gültigkeitsbereich
nicht zulässig.

Seit Python 3.6 kann in einer "async def"-Funktion eine "async
for"-Klausel verwendet werden, um einen *asynchronen Iterator* zu
durchlaufen. Ein Comprehension in einer "async def"-Funktion kann
entweder aus einer "for" - oder einer "async for"-Klausel bestehen,
die auf den einleitenden Ausdruck folgt, kann zusätzliche "for" - oder
"async for"-Klauseln enthalten und darf auch "await" -Ausdrücke
verwenden.

Wenn eine Comprehension "async for"-Klauseln enthält oder wenn sie
"await" -Ausdrücke oder andere asynchrone Comprehensions an einer
anderen Stelle als im iterierbaren Ausdruck in der ganz links
stehenden "for" -Klausel enthält, wird sie als *asynchrone
Comprehension* bezeichnet. Ein asynchrones Comprehension kann die
Ausführung der Coroutine-Funktion, in der es vorkommt, unterbrechen.
Siehe auch **PEP 530**.

Added in version 3.6: Es wurden asynchrone Comprehensions eingeführt.

Geändert in Version 3.8: "yield" und  "yield from"  ist im implizit
verschachtelten Gültigkeitsbereich verboten.

Geändert in Version 3.11: Asynchrone Comprehensions sind nun innerhalb
von Comprehensions in asynchronen Funktionen zulässig. Äußere
Comprehensions werden implizit asynchron.


6.2.5. Listenanzeigen
---------------------

Eine Listenangabe ist eine möglicherweise leere Folge von Ausdrücken,
die in eckige Klammern gesetzt ist:

   list_display ::= "[" [flexible_expression_list | comprehension] "]"

Eine Listendarstellung liefert ein neues Listenobjekt, dessen Inhalt
entweder durch eine Liste von Ausdrücken oder durch eine
Listeauswertung festgelegt wird.  Wird eine durch Kommas getrennte
Liste von Ausdrücken angegeben, werden deren Elemente von links nach
rechts ausgewertet und in dieser Reihenfolge in das Listenobjekt
eingefügt.  Wird eine Liste durch eine Comprehension angegeben, wird
die Liste aus den Elementen gebildet, die sich aus der Comprehension
ergeben.


6.2.6. Anzeigen einstellen
--------------------------

Eine Set-Darstellung wird durch geschweifte Klammern gekennzeichnet
und unterscheidet sich von Wörterbuch-Darstellungen dadurch, dass
keine Doppelpunkte die Schlüssel und Werte voneinander trennen:

   set_display ::= "{" (flexible_expression_list | comprehension) "}"

Eine Set-Anweisung liefert ein neues, veränderbares Set-Objekt, dessen
Inhalt entweder durch eine Folge von Ausdrücken oder durch eine
Comprehension festgelegt wird.  Wird eine durch Kommas getrennte Liste
von Ausdrücken angegeben, werden deren Elemente von links nach rechts
ausgewertet und dem Set-Objekt hinzugefügt. Wird ein Verständnis
angegeben, wird das Set aus den Elementen gebildet, die sich aus dem
Verständnis ergeben.

Eine leere Menge lässt sich mit ` "{}`" nicht erstellen; dieses
Literal erzeugt ein leeres Wörterbuch.


6.2.7. Wörterbuchanzeigen
-------------------------

Eine Wörterbuchdarstellung ist eine möglicherweise leere Folge von
Wörterbucheinträgen (Schlüssel-Wert-Paare), die in geschweifte
Klammern gesetzt sind:

   dict_display       ::= "{" [dict_item_list | dict_comprehension] "}"
   dict_item_list     ::= dict_item ("," dict_item)* [","]
   dict_item          ::= expression ":" expression | "**" or_expr
   dict_comprehension ::= expression ":" expression comp_for

Ein Aufruf der dictionary-Methode liefert ein neues Dictionary-Objekt
zurück.

Wenn eine durch Kommas getrennte Folge von Wörterbucheinträgen
angegeben wird, werden diese von links nach rechts ausgewertet, um die
Einträge des Wörterbuchs zu definieren: Jedes Schlüsselobjekt wird als
Schlüssel im Wörterbuch verwendet, um den entsprechenden Wert zu
speichern.  Das bedeutet, dass Sie denselben Schlüssel in der Liste
der Dict-Elemente mehrfach angeben können; der Wert für diesen
Schlüssel im endgültigen Dict ist dann der zuletzt angegebene.

Ein doppeltes Sternchen "**" steht für *Dictionary-Unpacking*. Sein
Operand muss ein *Mapping* sein. Jedes Mapping-Element wird dem neuen
Wörterbuch hinzugefügt. Spätere Werte ersetzen Werte, die bereits
durch frühere Wörterbucheinträge und frühere Dictionary-Unpackings
gesetzt wurden.

Added in version 3.5: Das Auspacken in Wörterbuchansichten,
ursprünglich vorgeschlagen von **PEP 448**.

Eine Dict-Komprehension benötigt im Gegensatz zu Listen- und Set-
Komprehensionen zwei durch einen Doppelpunkt getrennte Ausdrücke,
gefolgt von den üblichen „for“- und „if“-Klauseln. Bei der Ausführung
der Komprehension werden die resultierenden Schlüssel- und
Wertelemente in der Reihenfolge, in der sie erzeugt werden, in das
neue Wörterbuch eingefügt.

Einschränkungen hinsichtlich der Typen der Schlüsselwerte sind weiter
oben im Abschnitt  Die Standardtyp-Hierarchie  aufgeführt.
(Zusammenfassend lässt sich sagen, dass der Schlüsseltyp *hashable*
sein sollte, was alle veränderbare Objekte ausschließt.) Konflikte
zwischen doppelten Schlüsseln werden nicht erkannt; es gilt der
zuletzt für einen bestimmten Schlüsselwert gespeicherte Wert (der in
der Anzeige textuell ganz rechts steht).

Geändert in Version 3.8: Vor Python 3.8 war die Auswertungsreihenfolge
von Schlüssel und Wert in Dict-Comprehensions nicht eindeutig
definiert. In CPython wurde der Wert vor dem Schlüssel ausgewertet. Ab
Version 3.8 wird der Schlüssel vor dem Wert ausgewertet, wie unter
**PEP 572** vorgeschlagen.


6.2.8. Generatorausdrücke
-------------------------

A generator expression is a compact generator notation in parentheses:

   generator_expression ::= "(" expression comp_for ")"

A generator expression yields a new generator object.  Its syntax is
the same as for comprehensions, except that it is enclosed in
parentheses instead of brackets or curly braces.

Variables used in the generator expression are evaluated lazily when
the "__next__()" method is called for the generator object (in the
same fashion as normal generators).  However, the iterable expression
in the leftmost "for" clause is immediately evaluated, and the
*iterator* is immediately created for that iterable, so that an error
produced while creating the iterator will be emitted at the point
where the generator expression is defined, rather than at the point
where the first value is retrieved. Subsequent "for" clauses and any
filter condition in the leftmost "for" clause cannot be evaluated in
the enclosing scope as they may depend on the values obtained from the
leftmost iterable. For example: "(x*y for x in range(10) for y in
range(x, x+10))".

The parentheses can be omitted on calls with only one argument.  See
section Calls for details.

To avoid interfering with the expected operation of the generator
expression itself, "yield" and "yield from" expressions are prohibited
in the implicitly defined generator.

If a generator expression contains either "async for" clauses or
"await" expressions it is called an *asynchronous generator
expression*.  An asynchronous generator expression returns a new
asynchronous generator object, which is an asynchronous iterator (see
Asynchrone Iteratoren).

Added in version 3.6: Es wurden asynchrone Generatorausdrücke
eingeführt.

Geändert in Version 3.7: Vor Python 3.7 konnten asynchrone
Generatorausdrücke nur in "async def"-Koroutinen verwendet werden. Ab
Version 3.7 können asynchrone Generatorausdrücke in jeder Funktion
verwendet werden.

Geändert in Version 3.8: "yield" und  "yield from"  ist im implizit
verschachtelten Gültigkeitsbereich verboten.


6.2.9. Yield Ausdrücke
----------------------

   yield_atom       ::= "(" yield_expression ")"
   yield_from       ::= "yield" "from" expression
   yield_expression ::= "yield" yield_list | yield_from

Der yield-Ausdruck wird bei der Definition einer *Generator*-Funktion
oder einer *asynchronen Generator*-Funktion verwendet und kann daher
nur im Körper einer Funktionsdefinition verwendet werden. Die
Verwendung einer yield-Anweisung im Funktionskörper führt dazu, dass
diese Funktion zu einer Generatorfunktion wird, und die Verwendung in
einem "async def"-Funktionskörper führt dazu, dass diese Coroutine-
Funktion zu einer asynchronen Generatorfunktion wird. Zum Beispiel:

   def gen():  # definiert eine Generatorfunktion
       yield 123

   async def agen(): # definiert eine asynchrone Generatorfunktion
       yield 123

Aufgrund ihrer Auswirkungen auf den übergeordneten Gültigkeitsbereich
sind  "yield" -Ausdrücke nicht als Teil der implizit definierten
Gültigkeitsbereiche zulässig, die zur Implementierung von
Comprehensions und Generatorausdrücken verwendet werden.

Geändert in Version 3.8: Yield-Ausdrücke sind in den implizit
verschachtelten Gültigkeitsbereichen verboten, die zur Implementierung
von Comprehensions und Generatorausdrücken verwendet werden.

Generatorfunktionen werden im Folgenden beschrieben, während
asynchrone Generatorfunktionen separat im Abschnitt  Asynchrone
Generatorfunktionen  behandelt werden.

Wenn eine Generatorfunktion aufgerufen wird, gibt sie einen Iterator
zurück, der als Generator bezeichnet wird. Dieser Generator steuert
dann die Ausführung der Generatorfunktion. Die Ausführung beginnt,
sobald eine der Methoden des Generators aufgerufen wird. Zu diesem
Zeitpunkt geht die Ausführung zum ersten *yield*-Ausdruck über, wo sie
erneut angehalten wird und den Wert von "yield_list" an den Aufrufer
des Generators zurückgibt – oder "None", falls "yield_list"
weggelassen wurde. Mit unterbrochen ist gemeint, dass der gesamte
lokale Zustand beibehalten wird, einschließlich der aktuellen
Bindungen lokaler Variablen, des Befehlszeigers, des internen
Auswertungsstapels und des Zustands der Ausnahmebehandlung. Wenn die
Ausführung durch den Aufruf einer der Methoden des Generators
fortgesetzt wird, kann die Funktion genau so weiterlaufen, als wäre
der "yield“-Ausdruck lediglich ein weiterer externer Aufruf. Der Wert
des *yield*-Ausdrucks nach der Wiederaufnahme hängt von der Methode
ab, die die Ausführung wieder aufgenommen hat. Wird "__next__()"
verwendet (typischerweise entweder über "for" oder die eingebaute
Funktion "next()"), so ist das Ergebnis "None". Andernfalls, wenn
"send()" verwendet wird, ist das Ergebnis der an diese Methode
übergebene Wert.

All dies macht Generatorfunktionen den Coroutinen sehr ähnlich: Sie
führen mehrfach ein "Yield“ aus, verfügen über mehr als einen
Einstiegspunkt und ihre Ausführung kann unterbrochen werden. Der
einzige Unterschied besteht darin, dass eine Generatorfunktion nicht
steuern kann, an welcher Stelle die Ausführung nach einem "Yield“
fortgesetzt werden soll; die Kontrolle wird stets an den Aufrufer des
Generators übergeben.

Yield-Ausdrücke sind an beliebiger Stelle in einem  "try" -Konstrukt
zulässig. Wird der Generator nicht wieder aufgenommen, bevor er
finalisiert wird (durch Erreichen einer Referenzanzahl von Null oder
durch Garbage Collection), wird die Methode  "close()"  des Generator-
Iterators aufgerufen, wodurch alle ausstehenden  "finally" -Klauseln
ausgeführt werden können.

Bei Verwendung von "yield from <expr>" muss der übergebene Ausdruck
ein iterierbares Objekt sein. Die durch die Iteration dieses
iterierbaren Objekts erzeugten Werte werden direkt an den Aufrufer der
Methoden des aktuellen Generators übergeben. Alle mit "send()"
übergebenen Werte und alle mit "throw()" übergebenen Ausnahmen werden
an den zugrunde liegenden Iterator weitergeleitet, sofern dieser über
die entsprechenden Methoden verfügt. Ist dies nicht der Fall, löst
"send()" entweder "AttributeError" oder "TypeError" aus, während
"throw()" die übergebene Ausnahme sofort auslöst.

Wenn der zugrunde liegende Iterator abgeschlossen ist, wird das
Attribut  "value"  der ausgelösten Instanz von  "StopIteration"  zum
Wert des yield-Ausdrucks. Dieser kann entweder explizit beim Auslösen
von  "StopIteration"  festgelegt werden oder automatisch, wenn es sich
bei dem Unteriterator um einen Generator handelt (durch Rückgabe eines
Werts aus dem Untergenerator).

Geändert in Version 3.3: "yield from <expr>" wurde hinzugefügt, um den
Kontrollfluss an einen Subiterator zu delegieren.

Die Klammern können weggelassen werden, wenn der Yield-Ausdruck der
einzige Ausdruck auf der rechten Seite einer Zuweisungsanweisung ist.

Siehe auch:

  **PEP 255** - Einfache Generatoren
     Der Vorschlag, Generatoren und die Anweisung  "yield"  in Python
     aufzunehmen.

  **PEP 342** - Coroutinen über erweiterte Generatoren
     Der Vorschlag, die API und die Syntax von Generatoren zu
     verbessern, damit sie als einfache Coroutinen genutzt werden
     können.

  **PEP 380** - Syntax für die Delegierung an einen Untergenerator
     Der Vorschlag zur Einführung der Syntax  "yield_from" , die die
     Delegierung an Untergeneratoren vereinfacht.

  **PEP 525** - Asynchrone Generatoren
     Der Vorschlag, der  **PEP 492**  erweiterte, indem er Coroutinen-
     Funktionen um Generator-Funktionen ergänzte.


6.2.9.1. Generator-Iterator-Methoden
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In diesem Unterabschnitt werden die Methoden eines Generator-Iterators
beschrieben. Mit ihnen lässt sich die Ausführung einer
Generatorfunktion steuern.

Beachten Sie, dass der Aufruf einer der unten aufgeführten Generator-
Methoden, während der Generator bereits ausgeführt wird, eine Ausnahme
vom Typ  "ValueError"  auslöst.

generator.__next__()

   Startet die Ausführung einer Generatorfunktion oder setzt sie beim
   zuletzt ausgeführten yield-Ausdruck fort. Wird eine
   Generatorfunktion mit der Methode "__next__()" fortgesetzt, ergibt
   der aktuelle yield-Ausdruck immer "None". Die Ausführung läuft dann
   bis zum nächsten yield-Ausdruck weiter, wo der Generator erneut
   angehalten wird und der Wert der "yield_list" an den Aufrufer von
   "__next__()" zurückgegeben wird. Endet der Generator, ohne einen
   weiteren Wert zu liefern, wird eine "StopIteration"-Ausnahme
   ausgelöst.

   Diese Methode wird normalerweise implizit aufgerufen, z. B. durch
   eine "for" -Schleife oder durch die integrierte Funktion "next()" .

generator.send(value)

   Setzt die Ausführung fort und "übermittelt“ einen Wert an die
   Generatorfunktion. Das Argument *value* wird zum Ergebnis des
   aktuellen Yield-Ausdrucks. Die Methode ` "send()" ` gibt den
   nächsten vom Generator ausgegebenen Wert zurück oder löst die
   Ausnahme ` "StopIteration" ` aus, wenn der Generator beendet wird,
   ohne einen weiteren Wert auszugeben. Wenn ` "send()" ` zum Starten
   des Generators aufgerufen wird, muss dies mit ` "None" ` als
   Argument erfolgen, da es keinen *yield*-Ausdruck gibt, der den Wert
   empfangen könnte.

generator.throw(value)
generator.throw(type[, value[, traceback]])

   Löst an der Stelle, an der der Generator angehalten wurde, eine
   Ausnahme aus und gibt den nächsten von der Generatorfunktion
   zurückgegebenen Wert zurück. Wenn der Generator beendet wird, ohne
   einen weiteren Wert zurückzugeben, wird eine Ausnahme vom Typ
   "StopIteration" ausgelöst. Wenn die Generatorfunktion die
   übergebene Ausnahme nicht abfängt oder eine andere Ausnahme
   auslöst, wird diese Ausnahme an den Aufrufer weitergeleitet.

   Im typischen Anwendungsfall wird dies mit einer einzigen
   Ausnahminstanz aufgerufen, ähnlich wie das Schlüsselwort "raise"
   verwendet wird.

   Aus Gründen der Abwärtskompatibilität wird jedoch die zweite
   Signatur unterstützt, die einer Konvention aus älteren Python-
   Versionen folgt. Das Argument *type* sollte eine Ausnahmeklasse
   sein, und *value* sollte eine Ausnahmeninstanz sein. Wird *value*
   nicht angegeben, wird der Konstruktor von *type* aufgerufen, um
   eine Instanz zu erhalten. Wird *traceback* angegeben, wird es der
   Ausnahme zugewiesen; andernfalls wird ein eventuell in *value*
   gespeichertes Attribut vom Typ "__traceback__" möglicherweise
   gelöscht.

   Geändert in Version 3.12: Die zweite Signatur (type[, value[,
   traceback]]) ist veraltet und wird möglicherweise in einer
   zukünftigen Version von Python entfernt.

generator.close()

   Löst an der Stelle, an der die Generatorfunktion angehalten wurde,
   eine "GeneratorExit" -Ausnahme aus (entspricht dem Aufruf von
   "throw(GeneratorExit)"). Die Ausnahme wird durch den yield-Ausdruck
   ausgelöst, an dem der Generator angehalten wurde. Wenn die
   Generatorfunktion die Ausnahme abfängt und einen Wert zurückgibt,
   wird dieser Wert von "close()" zurückgegeben. Wenn die
   Generatorfunktion bereits geschlossen ist oder eine "GeneratorExit"
   auslöst (indem sie die Ausnahme nicht abfängt), gibt "close()"
   "None" zurück. Wenn der Generator einen Wert liefert, wird eine
   "RuntimeError" ausgelöst. Löst der Generator eine andere Ausnahme
   aus, wird diese an den Aufrufer weitergeleitet. Wenn der Generator
   aufgrund einer Ausnahme oder eines normalen Abbruchs bereits
   beendet wurde, gibt "close()" "None" zurück und hat keine weiteren
   Auswirkungen.

   Geändert in Version 3.13: Wenn ein Generator beim Schließen einen
   Wert zurückgibt, wird dieser Wert von "close()" zurückgegeben.


6.2.9.2. Beispiele
~~~~~~~~~~~~~~~~~~

Hier ist ein einfaches Beispiel, das das Verhalten von Generatoren und
Generatorfunktionen veranschaulicht:

   >>> def echo(value=None):
   ...     print("Die Ausführung beginnt, wenn 'next()' zum ersten Mal aufgerufen wird.")
   ...     try:
   ...         while True:
   ...             try:
   ...                 value = (yield value)
   ...             except Exception as e:
   ...                 value = e
   ...     finally:
   ...         print("Vergiss nicht, beim Aufruf von 'close()' aufzuräumen.")
   ...
   >>> generator = echo(1)
   >>> print(next(generator))
   Die Ausführung beginnt, wenn „next()“ zum ersten Mal aufgerufen wird.
   1
   >>> print(next(generator))
   None
   >>> print(generator.send(2))
   2
   >>> generator.throw(TypeError, "spam")
   TypeError('spam',)
   >>> generator.close()
   Vergiss nicht, die Ressourcen freizugeben, wenn 'close()' aufgerufen wird.

Beispiele für die Verwendung von ` "yield from`" finden Sie unter PEP
380: Syntax for Delegating to a Subgenerator im Abschnitt "Neuerungen
in Python“.


6.2.9.3. Asynchrone Generatorfunktionen
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Das Vorhandensein eines Yield-Ausdrucks in einer Funktion oder
Methode, die mit "async def" definiert wurde, definiert die Funktion
zusätzlich als *asynchronen Generator*.

Wenn eine asynchrone Generatorfunktion aufgerufen wird, gibt sie einen
asynchronen Iterator zurück, der als asynchrones Generatorobjekt
bezeichnet wird. Dieses Objekt steuert dann die Ausführung der
Generatorfunktion. Ein asynchrones Generatorobjekt wird typischerweise
in einer "async for"-Anweisung in einer Coroutine-Funktion verwendet,
analog dazu, wie ein Generatorobjekt in einer "for" -Anweisung
verwendet würde.

Der Aufruf einer der Methoden des asynchronen Generators gibt ein
*awaitable*-Objekt zurück, und die Ausführung beginnt, sobald auf
dieses Objekt gewartet wird. Dann läuft die Ausführung bis zum ersten
yield-Ausdruck, wo sie erneut angehalten wird und der Wert der
"yield_list" an die wartende Coroutine zurückgegeben wird. Wie bei
einem Generator bedeutet Anhalten, dass der gesamte lokale Zustand
erhalten bleibt – die aktuellen Bindungen der lokalen Variablen, der
Befehlszeiger, der interne Auswertungsstapel und der Zustand jeder
Ausnahmebehandlung. Wird die Ausführung fortgesetzt, indem auf das
nächste von den Methoden des asynchronen Generators zurückgegebene
Objekt gewartet wird, kann die Funktion genauso weiterlaufen, als wäre
der yield-Ausdruck lediglich ein weiterer externer Aufruf. Welchen
Wert der yield-Ausdruck nach dem Fortsetzen hat, hängt von der Methode
ab, die die Ausführung fortgesetzt hat. Wird "__anext__()" verwendet,
ist das Ergebnis "None". Wird dagegen "asend()" verwendet, ist das
Ergebnis der Wert, der dieser Methode übergeben wurde.

Wenn ein asynchroner Generator vorzeitig beendet wird – sei es durch
"break" , die Abbruch der aufrufenden Aufgabe oder andere Ausnahmen –,
wird der asynchrone Bereinigungscode des Generators ausgeführt und
löst möglicherweise Ausnahmen aus oder greift auf Kontextvariablen in
einem unerwarteten Kontext zu – etwa nach Ablauf der Lebensdauer der
Aufgaben, von denen er abhängt, oder während des Herunterfahrens der
Ereignisschleife, wenn der Garbage-Collection-Hook des asynchronen
Generators aufgerufen wird. Um dies zu verhindern, muss der Aufrufer
den asynchronen Generator explizit schließen, indem er die Methode `
"aclose()" ` aufruft, um den Generator zu finalisieren und ihn
schließlich von der Ereignisschleife zu trennen.

In einer asynchronen Generatorfunktion sind „yield“-Ausdrücke an jeder
Stelle innerhalb eines "try" -Konstrukts zulässig. Wird ein
asynchroner Generator jedoch nicht fortgesetzt, bevor er finalisiert
wird (durch Erreichen einer Referenzanzahl von Null oder durch Garbage
Collection), kann ein „yield“-Ausdruck innerhalb eines "try"
-Konstrukts dazu führen, dass ausstehende "finally" -Klauseln nicht
ausgeführt werden. In diesem Fall liegt es in der Verantwortung der
Ereignisschleife oder des Schedulers, die bzw. der den asynchronen
Generator ausführt, die Methode "aclose()" des asynchronen Generator-
Iterators aufzurufen und das resultierende Coroutine-Objekt
auszuführen, wodurch die Ausführung aller ausstehenden
"finally"-Klauseln ermöglicht wird.

Um die Finalisierung nach Beendigung der Ereignisschleife zu
gewährleisten, sollte eine Ereignisschleife eine *finalizer*-Funktion
definieren, die einen asynchronen Generator-Iterator entgegennimmt und
vermutlich "aclose()" aufruft und die Coroutine ausführt. Dieser
*finalizer* kann durch den Aufruf von "sys.set_asyncgen_hooks()"
registriert werden. Bei der ersten Iteration speichert ein asynchroner
Generator-Iterator den registrierten *finalizer*, der bei der
Finalisierung aufgerufen werden soll. Ein Referenzbeispiel für eine
*finalizer*-Methode finden Sie in der Implementierung von
"asyncio.Loop.shutdown_asyncgens" unter Lib/asyncio/base_events.py.

Der Ausdruck "yield from <expr>" führt zu einem Syntaxfehler, wenn er
in einer asynchronen Generatorfunktion verwendet wird.


6.2.9.4. Asynchrone Generator-Iterator-Methoden
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In diesem Unterabschnitt werden die Methoden eines asynchronen
Generator-Iterators beschrieben, die zur Steuerung der Ausführung
einer Generatorfunktion verwendet werden.

async agen.__anext__()

   Gibt ein "Awaitable“ zurück, das bei der Ausführung die Ausführung
   des asynchronen Generators startet oder diesen an der zuletzt
   ausgeführten "yield“-Anweisung fortsetzt. Wenn eine asynchrone
   Generatorfunktion mit einer "__anext__()" -Methode fortgesetzt
   wird, ergibt die aktuelle "yield“-Anweisung im zurückgegebenen
   "Awaitable“ stets den Wert "None" , wodurch bei der Ausführung zum
   nächsten "yield“-Ausdruck übergegangen wird. Der Wert von `
   "yield_list" ` des *yield*-Ausdrucks ist der Wert der Ausnahme `
   "StopIteration" *, die von der abgeschlossenen Coroutine ausgelöst
   wurde. Wenn der asynchrone Generator beendet wird, ohne einen
   weiteren Wert auszugeben, löst das `awaitable* stattdessen eine
   Ausnahme vom Typ ` "StopAsyncIteration" ` aus, um zu signalisieren,
   dass die asynchrone Iteration abgeschlossen ist.

   Diese Methode wird normalerweise implizit von einer "async
   for"-Schleife aufgerufen.

async agen.asend(value)

   Gibt ein "Awaitable“ zurück, das bei Ausführung die Ausführung des
   asynchronen Generators fortsetzt. Wie bei der Methode "send()" für
   einen Generator wird dadurch ein Wert an die asynchrone
   Generatorfunktion „gesendet“, und das Argument *value* wird zum
   Ergebnis des aktuellen "yield“-Ausdrucks. Das von der Methode
   "asend()" zurückgegebene "awaitable“-Objekt gibt den nächsten vom
   Generator ausgegebenen Wert als Wert der ausgelösten Ausnahme
   "StopIteration" zurück oder löst "StopAsyncIteration" aus, wenn der
   asynchrone Generator beendet wird, ohne einen weiteren Wert
   auszugeben. Wenn "asend()" aufgerufen wird, um den asynchronen
   Generator zu starten, muss dies mit "None" als Argument erfolgen,
   da es keinen "yield“-Ausdruck gibt, der den Wert empfangen könnte.

async agen.athrow(value)
async agen.athrow(type[, value[, traceback]])

   Gibt ein "Awaitable“ zurück, das an der Stelle, an der der
   asynchrone Generator angehalten wurde, eine Ausnahme vom Typ "type"
   auslöst und den nächsten von der Generatorfunktion ausgegebenen
   Wert als Wert der ausgelösten "StopIteration" -Ausnahme zurückgibt.
   Wenn der asynchrone Generator beendet wird, ohne einen weiteren
   Wert auszugeben, löst das "Awaitable“ eine "StopAsyncIteration"
   -Ausnahme aus. Wenn die Generatorfunktion die übergebene Ausnahme
   nicht abfängt oder eine andere Ausnahme auslöst, wird diese
   Ausnahme bei der Ausführung des "awaitable“ an den Aufrufer des
   "awaitable“ weitergeleitet.

   Geändert in Version 3.12: Die zweite Signatur (type[, value[,
   traceback]]) ist veraltet und wird möglicherweise in einer
   zukünftigen Version von Python entfernt.

async agen.aclose()

   Gibt ein "Awaitable“ zurück, das bei Ausführung in der asynchronen
   Generatorfunktion an der Stelle, an der sie angehalten wurde, eine
   "GeneratorExit" -Ausnahme auslöst. Wenn die asynchrone
   Generatorfunktion anschließend ordnungsgemäß beendet wird, bereits
   geschlossen ist oder eine "GeneratorExit" -Ausnahme auslöst (indem
   die Ausnahme nicht abgefangen wird), löst das zurückgegebene
   "Awaitable“ eine "StopIteration" -Ausnahme aus. Alle weiteren
   "awaitables“, die durch nachfolgende Aufrufe des asynchronen
   Generators zurückgegeben werden, lösen eine "StopAsyncIteration"
   -Ausnahme aus. Wenn der asynchrone Generator einen Wert liefert,
   löst das "awaitable“ eine "RuntimeError" -Ausnahme aus. Löst der
   asynchrone Generator eine andere Ausnahme aus, wird diese an den
   Aufrufer des "awaitable“ weitergeleitet. Wenn der asynchrone
   Generator bereits aufgrund einer Ausnahme oder eines normalen
   Abbruchs beendet wurde, geben weitere Aufrufe von "aclose()" ein
   "awaitable“ zurück, das keine Aktion ausführt.


6.3. Primäre Funktionen
=======================

Primäre Funktionen stellen die am stärksten eingebundenen Operationen
der Sprache dar. Ihre Syntax lautet:

   primary ::= atom | attributeref | subscription | slicing | call


6.3.1. Attributverweise
-----------------------

Eine Attributreferenz besteht aus einem Primärattribut, gefolgt von
einem Punkt und einem Namen:

   attributeref ::= primary "." identifier

Die Primäre Funktion muss zu einem Objekt eines Typs ausgewertet
werden, der Attributverweise unterstützt – was bei den meisten
Objekten der Fall ist. Dieses Objekt wird dann aufgefordert, das
Attribut mit dem Namen des Bezeichners bereitzustellen. Der Typ und
der Wert des bereitgestellten Attributs werden vom Objekt bestimmt.
Mehrere Auswertungen desselben Attributverweises können zu
unterschiedlichen Objekten führen.

Diese Implementierung kann angepasst werden, indem die Methode
"__getattribute__()" oder die Methode "__getattr__()" überschrieben
wird. Die Methode "__getattribute__()" wird zuerst aufgerufen und gibt
entweder einen Wert zurück oder löst eine "AttributeError" -Ausnahme
aus, falls das Attribut nicht verfügbar ist.

Wird eine "AttributeError" ausgelöst und verfügt das Objekt über eine
"__getattr__()" -Methode, wird diese Methode als Fallback aufgerufen.


6.3.2. Subscriptions
--------------------

The subscription of an instance of a container class will generally
select an element from the container. The subscription of a *generic
class* will generally return a GenericAlias object.

   subscription ::= primary "[" flexible_expression_list "]"

When an object is subscripted, the interpreter will evaluate the
primary and the expression list.

The primary must evaluate to an object that supports subscription. An
object may support subscription through defining one or both of
"__getitem__()" and "__class_getitem__()". When the primary is
subscripted, the evaluated result of the expression list will be
passed to one of these methods. For more details on when
"__class_getitem__" is called instead of "__getitem__", see
__class_getitem__ im Vergleich zu __getitem__.

If the expression list contains at least one comma, or if any of the
expressions are starred, the expression list will evaluate to a
"tuple" containing the items of the expression list. Otherwise, the
expression list will evaluate to the value of the list's sole member.

Geändert in Version 3.11: Expressions in an expression list may be
starred. See **PEP 646**.

For built-in objects, there are two types of objects that support
subscription via "__getitem__()":

1. Mappings. If the primary is a *mapping*, the expression list must
   evaluate to an object whose value is one of the keys of the
   mapping, and the subscription selects the value in the mapping that
   corresponds to that key. An example of a builtin mapping class is
   the "dict" class.

2. Sequences. If the primary is a *sequence*, the expression list must
   evaluate to an "int" or a "slice" (as discussed in the following
   section). Examples of builtin sequence classes include the "str",
   "list" and "tuple" classes.

The formal syntax makes no special provision for negative indices in
*sequences*. However, built-in sequences all provide a "__getitem__()"
method that interprets negative indices by adding the length of the
sequence to the index so that, for example, "x[-1]" selects the last
item of "x". The resulting value must be a nonnegative integer less
than the number of items in the sequence, and the subscription selects
the item whose index is that value (counting from zero). Since the
support for negative indices and slicing occurs in the object's
"__getitem__()" method, subclasses overriding this method will need to
explicitly add that support.

A "string" is a special kind of sequence whose items are *characters*.
A character is not a separate data type but a string of exactly one
character.


6.3.3. Slicings
---------------

A slicing selects a range of items in a sequence object (e.g., a
string, tuple or list).  Slicings may be used as expressions or as
targets in assignment or "del" statements.  The syntax for a slicing:

   slicing      ::= primary "[" slice_list "]"
   slice_list   ::= slice_item ("," slice_item)* [","]
   slice_item   ::= expression | proper_slice
   proper_slice ::= [lower_bound] ":" [upper_bound] [ ":" [stride] ]
   lower_bound  ::= expression
   upper_bound  ::= expression
   stride       ::= expression

There is ambiguity in the formal syntax here: anything that looks like
an expression list also looks like a slice list, so any subscription
can be interpreted as a slicing.  Rather than further complicating the
syntax, this is disambiguated by defining that in this case the
interpretation as a subscription takes priority over the
interpretation as a slicing (this is the case if the slice list
contains no proper slice).

The semantics for a slicing are as follows.  The primary is indexed
(using the same "__getitem__()" method as normal subscription) with a
key that is constructed from the slice list, as follows.  If the slice
list contains at least one comma, the key is a tuple containing the
conversion of the slice items; otherwise, the conversion of the lone
slice item is the key.  The conversion of a slice item that is an
expression is that expression.  The conversion of a proper slice is a
slice object (see section Die Standardtyp-Hierarchie) whose "start",
"stop" and "step" attributes are the values of the expressions given
as lower bound, upper bound and stride, respectively, substituting
"None" for missing expressions.


6.3.4. Calls
------------

Ein Aufruf (Call) ruft ein aufrufbares Objekt (z. B. eine *Funktion*)
mit einer möglicherweise leeren Folge von *Argumenten* auf:

   call                 ::= primary "(" [argument_list [","] | comprehension] ")"
   argument_list        ::= positional_arguments ["," starred_and_keywords]
                            ["," keywords_arguments]
                            | starred_and_keywords ["," keywords_arguments]
                            | keywords_arguments
   positional_arguments ::= positional_item ("," positional_item)*
   positional_item      ::= assignment_expression | "*" expression
   starred_and_keywords ::= ("*" expression | keyword_item)
                            ("," "*" expression | "," keyword_item)*
   keywords_arguments   ::= (keyword_item | "**" expression)
                            ("," keyword_item | "," "**" expression)*
   keyword_item         ::= identifier "=" expression

Nach den Positions- und Schlüsselwortargumenten kann ein optionales
abschließendes Komma stehen, das jedoch keinen Einfluss auf die
Semantik hat.

Der Primärausdruck muss zu einem aufrufbaren Objekt ausgewertet werden
(benutzerdefinierte Funktionen, integrierte Funktionen, Methoden
integrierter Objekte, Klassenobjekte, Methoden von Klasseninstanzen
sowie alle Objekte, die über eine Methode "__call__()" verfügen, sind
aufrufbar). Alle Argumentausdrücke werden ausgewertet, bevor der
Aufruf versucht wird. Informationen zur Syntax formaler
*Parameter*-Listen finden Sie im Abschnitt Funktionsdefinitionen .

Sind Schlüsselwortargumente vorhanden, werden diese zunächst wie folgt
in Positionsargumente umgewandelt. Zunächst wird eine Liste mit noch
nicht belegten Slots für die formalen Parameter erstellt. Gibt es N
Positionsargumente, werden diese in die ersten N Slots eingefügt.
Anschließend wird für jedes Schlüsselwortargument anhand des
Bezeichners der entsprechende Platz bestimmt (stimmt der Bezeichner
mit dem Namen des ersten formalen Parameters überein, wird der erste
Platz verwendet usw.). Ist der Platz bereits belegt, wird eine
Ausnahme vom Typ "TypeError" ausgelöst. Andernfalls wird das Argument
in den Slot gesetzt und füllt diesen aus (selbst wenn der Ausdruck
"None" lautet, füllt er den Slot aus). Wenn alle Argumente verarbeitet
wurden, werden die noch unbesetzten Slots mit dem entsprechenden
Standardwert aus der Funktionsdefinition gefüllt. (Standardwerte
werden einmalig bei der Definition der Funktion berechnet; daher wird
ein veränderbares Objekt wie eine Liste oder ein Wörterbuch, das als
Standardwert verwendet wird, von allen Aufrufen gemeinsam genutzt, die
keinen Argumentwert für den entsprechenden Slot angeben; dies sollte
in der Regel vermieden werden.) Wenn es ungefüllte Slots gibt, für die
kein Standardwert angegeben ist, wird eine Ausnahme vom Typ
"TypeError" ausgelöst. Andernfalls wird die Liste der gefüllten Slots
als Argumentliste für den Aufruf verwendet.

Eine Implementierung kann integrierte Funktionen bereitstellen, deren
Positionsparameter keine Namen haben – auch wenn sie zu
Dokumentationszwecken "benannt“ sind – und die daher nicht per
Schlüsselwort übergeben werden können. In CPython ist dies bei
Funktionen der Fall, die in C implementiert sind und `
"PyArg_ParseTuple()" ` zum Parsen ihrer Argumente verwenden.

Wenn mehr Positionsargumente vorhanden sind als formale
Parameterplätze, wird eine Ausnahme vom Typ "TypeError" ausgelöst, es
sei denn, es ist ein formaler Parameter vorhanden, der die Syntax
"*identifier" verwendet; in diesem Fall erhält dieser formale
Parameter ein Tupel, das die überschüssigen Positionsargumente enthält
(oder ein leeres Tupel, falls keine überschüssigen Positionsargumente
vorhanden waren).

Wenn ein Schlüsselwortargument keinem formalen Parameternamen
entspricht, wird eine Ausnahme vom Typ "TypeError" ausgelöst, es sei
denn, es ist ein formaler Parameter vorhanden, der die Syntax
"**identifier" verwendet; in diesem Fall erhält dieser formale
Parameter ein Wörterbuch, das die überschüssigen
Schlüsselwortargumente enthält (wobei die Schlüsselwörter als
Schlüssel und die Argumentwerte als entsprechende Werte dienen), oder
ein (neues) leeres Wörterbuch, falls keine überschüssigen
Schlüsselwortargumente vorhanden waren.

Wenn die Syntax "*expression" im Funktionsaufruf vorkommt, muss
"expression" zu einem *iterable* ausgewertet werden. Elemente aus
diesen Iterables werden so behandelt, als wären sie zusätzliche
Positionsargumente. Für den Aufruf "f(x1, x2, *y, x3, x4)" gilt: Wenn
*y* zu einer Sequenz *y1*, ..., *yM* ausgewertet wird, entspricht dies
einem Aufruf mit M+4 Positionsargumenten *x1*, *x2*, *y1*, ..., *yM*,
*x3*, *x4*.

Dies hat zur Folge, dass die Syntax "*expression" zwar *nach*
expliziten Schlüsselwortargumenten stehen kann, jedoch *vor* den
Schlüsselwortargumenten (und etwaigen "**expression" -Argumenten –
siehe unten) verarbeitet wird. Also:

   >>> def f(a, b):
   ...     print(a, b)
   ...
   >>> f(b=1, *(2,))
   2 1
   >>> f(a=1, *(2,))
   Traceback (letzter Aufruf zuletzt):
    Datei „<stdin> “, Zeile 1, in <module>
   TypeError: f() hat mehrere Werte für das Schlüsselwortargument 'a' erhalten
   >>> f(1, *(2,))
   1 2

Es kommt selten vor, dass sowohl Schlüsselwortargumente als auch die
Syntax "*expression" in ein und demselben Aufruf verwendet werden,
sodass diese Verwirrung in der Praxis nicht oft auftritt.

Wenn im Funktionsaufruf die Syntax "**expression" erscheint, muss
"expression" zu einem *mapping* ausgewertet werden, dessen Inhalt als
zusätzliche Schlüsselwortargumente behandelt wird. Wenn einem
Schlüssel bereits ein Wert zugewiesen wurde (durch ein explizites
Schlüsselwortargument oder durch eine andere Entpackung), wird eine
Ausnahme vom Typ "TypeError" ausgelöst.

Bei Verwendung von ` "**expression" ` muss jeder Schlüssel in dieser
Zuordnung eine Zeichenkette sein. Jeder Wert aus der Zuordnung wird
dem ersten formalen Parameter zugewiesen, der für eine Zuweisung über
ein Schlüsselwort in Frage kommt und dessen Name mit dem Schlüssel
übereinstimmt. Ein Schlüssel muss kein Python-Bezeichner sein (z. B.
ist ""max-temp °F"" zulässig, obwohl er mit keinem formalen Parameter
übereinstimmt, der deklariert werden könnte). Wenn keine
Übereinstimmung mit einem formalen Parameter vorliegt, wird das
Schlüssel-Wert-Paar vom Parameter "**" erfasst, sofern vorhanden;
andernfalls wird eine Ausnahme vom Typ "TypeError" ausgelöst.

Formale Parameter mit der Syntax "*identifier" oder "**identifier"
dürfen nicht als Positionsargumente oder als Namen für
Schlüsselwortargumente verwendet werden.

Geändert in Version 3.5: Funktionsaufrufe akzeptieren eine beliebige
Anzahl von "*" - und "**" -Entpackungen; auf iterierbare Entpackungen
("*") können Positionsargumente folgen, und auf Dictionary-
Entpackungen ("**") können Schlüsselwortargumente folgen. Ursprünglich
vorgeschlagen von **PEP 448**.

A call always returns some value, possibly "None", unless it raises an
exception.  How this value is computed depends on the type of the
callable object.

Wenn es so ist---

eine benutzerdefinierte Funktion:
   Der Codeblock für die Funktion wird ausgeführt, wobei ihm die
   Argumentliste übergeben wird. Als Erstes ordnet der Codeblock die
   formalen Parameter den Argumenten zu; dies wird im Abschnitt
   Funktionsdefinitionen beschrieben. Wenn der Codeblock eine
   Anweisung "return" ausführt, legt diese den Rückgabewert des
   Funktionsaufrufs fest. Erreicht die Ausführung das Ende des
   Codeblocks, ohne dass eine Anweisung "return" ausgeführt wurde, ist
   der Rückgabewert "None" .

eine integrierte Funktion oder Methode:
   Das Ergebnis hängt vom Interpreter ab; unter Integrierte Funktionen
   finden Sie Beschreibungen der integrierten Funktionen und Methoden.

ein Klassenobjekt:
   Es wird eine neue Instanz dieser Klasse zurückgegeben.

eine Klasseninstanzmethode:
   Die entsprechende benutzerdefinierte Funktion wird mit einer
   Argumentliste aufgerufen, die um ein Element länger ist als die
   Argumentliste des Aufrufs: Die Instanz wird zum ersten Argument.

eine Klasseninstanz:
   Die Klasse muss eine Methode "__call__()" definieren; die
   Auswirkung ist dann dieselbe, als wäre diese Methode aufgerufen
   worden.


6.4. Ausdruck "Await“
=====================

Die Ausführung einer *Coroutine* für ein *awaitable*-Objekt
unterbrechen. Kann nur innerhalb einer *Coroutine-Funktion* verwendet
werden.

   await_expr ::= "await" primary

Added in version 3.5.


6.5. Der Potenz Operator (Power Operator)
=========================================

Eine Potenz ist eine kurze Schreibweise für eine mehrfache
Multiplikation derselben Zahl.. Der Potenz Operator hat eine stärkere
Bindungsstärke als unäre Operatoren zu seiner Linken; zu seiner
Rechten hat er eine geringere Bindungsstärke. Die Syntax lautet:

   power ::= (await_expr | primary) ["**" u_expr]

In einer Kette aus Potenz- und unären Operatoren ohne Klammern werden
die Operatoren also von rechts nach links ausgewertet (dies schränkt
die Auswertungsreihenfolge der Operanden nicht ein): "-1**2" ergibt
"-1" .

The power operator has the same semantics as the built-in "pow()"
function, when called with two arguments: it yields its left argument
raised to the power of its right argument.  The numeric arguments are
first converted to a common type, and the result is of that type.

Bei int-Operanden hat das Ergebnis denselben Typ wie die Operanden, es
sei denn, das zweite Argument ist negativ; in diesem Fall werden alle
Argumente in float konvertiert und es wird ein float-Ergebnis
zurückgegeben. Beispielsweise gibt "10**2" das Ergebnis "100" zurück,
während "10**-2" das Ergebnis "0.01" liefert.

Wird "0.0" mit einer negativen Potenz potenziert, ergibt sich
"ZeroDivisionError" . Wird eine negative Zahl mit einer gebrochenen
Potenz potenziert, ergibt sich eine "complex" -Zahl. (In früheren
Versionen ergab dies eine "ValueError" .)

Diese Operation kann mithilfe der speziellen Methoden "__pow__()" und
"__rpow__()" angepasst werden.


6.6. Unäre Arithmetik und bitweise Operationen
==============================================

Alle unären arithmetischen und bitweisen Operationen haben dieselbe
Priorität:

   u_expr ::= power | "-" u_expr | "+" u_expr | "~" u_expr

Der unäre Operator "-" (Minus) liefert die Negation seines numerischen
Arguments; die Operation kann mit der speziellen Methode "__neg__()"
überschrieben werden.

Der unäre Operator "+" (Plus) gibt sein numerisches Argument
unverändert zurück; die Operation kann mit der speziellen Methode
"__pos__()" überschrieben werden.

The unary "~" (invert) operator yields the bitwise inversion of its
integer argument.  The bitwise inversion of "x" is defined as
"-(x+1)".  It only applies to integral numbers or to custom objects
that override the "__invert__()" special method.

In allen drei Fällen wird eine "TypeError" -Ausnahme ausgelöst, wenn
das Argument nicht den richtigen Typ hat.


6.7. Binäre arithmetische Operationen
=====================================

Die binären arithmetischen Operationen folgen den üblichen
Prioritätsstufen. Beachten Sie, dass einige dieser Operationen auch
für bestimmte nicht-numerische Typen gelten. Abgesehen vom
Potenzoperator gibt es nur zwei Ebenen, eine für multiplikative
Operatoren und eine für additive Operatoren:

   m_expr ::= u_expr | m_expr "*" u_expr | m_expr "@" m_expr |
              m_expr "//" u_expr | m_expr "/" u_expr |
              m_expr "%" u_expr
   a_expr ::= m_expr | a_expr "+" m_expr | a_expr "-" m_expr

The "*" (multiplication) operator yields the product of its arguments.
The arguments must either both be numbers, or one argument must be an
integer and the other must be a sequence. In the former case, the
numbers are converted to a common type and then multiplied together.
In the latter case, sequence repetition is performed; a negative
repetition factor yields an empty sequence.

Diese Operation kann mithilfe der speziellen Methoden „"__mul__()" und
"__rmul__()" angepasst werden.

The "@" (at) operator is intended to be used for matrix
multiplication.  No builtin Python types implement this operator.

Diese Operation kann mithilfe der speziellen Methoden "__matmul__()"
und "__rmatmul__()" angepasst werden.

Added in version 3.5.

The "/" (division) and "//" (floor division) operators yield the
quotient of their arguments.  The numeric arguments are first
converted to a common type. Division of integers yields a float, while
floor division of integers results in an integer; the result is that
of mathematical division with the 'floor' function applied to the
result.  Division by zero raises the "ZeroDivisionError" exception.

Die Division kann mithilfe der speziellen Methoden "__truediv__()" und
"__rtruediv__()" angepasst werden. Die Rundung nach unten kann
mithilfe der speziellen Methoden "__floordiv__()" und
"__rfloordiv__()" angepasst werden.

The "%" (modulo) operator yields the remainder from the division of
the first argument by the second.  The numeric arguments are first
converted to a common type.  A zero right argument raises the
"ZeroDivisionError" exception.  The arguments may be floating-point
numbers, e.g., "3.14%0.7" equals "0.34" (since "3.14" equals "4*0.7 +
0.34".)  The modulo operator always yields a result with the same sign
as its second operand (or zero); the absolute value of the result is
strictly smaller than the absolute value of the second operand [1].

Die Floor-Division und der Modulo-Operator sind durch die folgende
Identität miteinander verbunden: "x == (x//y)*y + (x%y)". Die Floor-
Division und der Modulo-Operator sind außerdem mit der integrierten
Funktion "divmod()" verbunden: "divmod(x, y) == (x//y, x%y)". [2].

Neben der Durchführung der Modulo-Operation an Zahlen wird der
Operator "%" auch von Zeichenfolgenobjekten überladen, um die
Zeichenfolgenformatierung im alten Stil (auch als Interpolation
bezeichnet) durchzuführen. Die Syntax für die
Zeichenfolgenformatierung wird in der Python-Bibliotheksreferenz im
Abschnitt String-Formatierung im printf-Stil beschrieben.

Die *Modulo*-Operation kann mithilfe der speziellen Methoden
"__mod__()" und "__rmod__()" angepasst werden.

Der Rundungsoperator, der Modulo-Operator und die Funktion "divmod()"
sind für komplexe Zahlen nicht definiert. Wandeln Sie den Wert
stattdessen gegebenenfalls mithilfe der Funktion "abs()" in eine
Gleitkommazahl um.

The "+" (addition) operator yields the sum of its arguments.  The
arguments must either both be numbers or both be sequences of the same
type.  In the former case, the numbers are converted to a common type
and then added together. In the latter case, the sequences are
concatenated.

Diese Operation kann mithilfe der speziellen Methoden "__add__()" und
"__radd__()" angepasst werden.

The "-" (subtraction) operator yields the difference of its arguments.
The numeric arguments are first converted to a common type.

Diese Operation kann mithilfe der speziellen Methoden "__sub__()" und
"__rsub__()" angepasst werden.


6.8. Verschiebungsoperationen
=============================

Die Verschiebungsoperationen haben eine niedrigere Priorität als die
arithmetischen Operationen:

   shift_expr ::= a_expr | shift_expr ("<<" | ">>") a_expr

Diese Operatoren akzeptieren Ganzzahlen als Argumente. Sie verschieben
das erste Argument um die im zweiten Argument angegebene Anzahl von
Bits nach links oder rechts.

Die Linksverschiebung kann mithilfe der speziellen Methoden
"__lshift__()" und "__rlshift__()" angepasst werden. Die
Rechtsverschiebung kann mithilfe der speziellen Methoden
"__rshift__()" und "__rrshift__()" angepasst werden.

A right shift by *n* bits is defined as floor division by "pow(2,n)".
A left shift by *n* bits is defined as multiplication with "pow(2,n)".


6.9. Binäre bitweise Operationen
================================

Jede der drei bitweisen Operationen hat eine andere Prioritätsstufe:

   and_expr ::= shift_expr | and_expr "&" shift_expr
   xor_expr ::= and_expr | xor_expr "^" and_expr
   or_expr  ::= xor_expr | or_expr "|" xor_expr

Der Operator "&" liefert das bitweise UND seiner Argumente, die
entweder Ganzzahlen sein müssen oder von denen eines ein
benutzerdefiniertes Objekt sein muss, das die speziellen Methoden
"__and__()" oder "__rand__()" überschreibt.

Der Operator "^" liefert das bitweise XOR (exklusives ODER) seiner
Argumente, die Ganzzahlen sein müssen oder von denen eines ein
benutzerdefiniertes Objekt sein muss, das die speziellen Methoden
"__xor__()" oder "__rxor__()" überschreibt.

Der Operator "|" liefert das bitweise (inklusives) ODER seiner
Argumente, bei denen es sich entweder um Ganzzahlen handeln muss oder
eines davon ein benutzerdefiniertes Objekt sein muss, das die
speziellen Methoden "__or__()" oder "__ror__()" überschreibt.


6.10. Vergleiche
================

Unlike C, all comparison operations in Python have the same priority,
which is lower than that of any arithmetic, shifting or bitwise
operation.  Also unlike C, expressions like "a < b < c" have the
interpretation that is conventional in mathematics:

   comparison    ::= or_expr (comp_operator or_expr)*
   comp_operator ::= "<" | ">" | "==" | ">=" | "<=" | "!="
                     | "is" ["not"] | ["not"] "in"

Vergleiche liefern boolesche Werte: "True" oder "False" .
Benutzerdefinierte *erweiterte Vergleichsmethoden* können nicht-
boolesche Werte zurückgeben. In diesem Fall ruft Python für solche
Werte in booleschen Kontexten die Funktion "bool()" auf.

Vergleiche können beliebig verkettet werden, z. B. ist "x < y <= z"
gleichbedeutend mit "x < y and y <= z" , mit dem Unterschied, dass "y"
nur einmal ausgewertet wird (in beiden Fällen wird "z" jedoch
überhaupt nicht ausgewertet, wenn "x < y" als falsch erkannt wird).

Formal gilt: Sind *a*, *b*, *c*, …, *y*, *z* Ausdrücke und *op1*,
*op2*, …, *opN* Vergleichsoperatoren, dann ist "a op1 b op2 c ... y
opN z" äquivalent zu "a op1 b and b op2 c and ... y opN z", mit der
Ausnahme, dass jeder Ausdruck höchstens einmal ausgewertet wird.

Beachten Sie, dass „ "a op1 b op2 c" “ keinerlei Vergleich zwischen
*a* und *c* impliziert, sodass beispielsweise „ "x < y > z" “ völlig
zulässig ist (wenn auch vielleicht nicht besonders elegant).


6.10.1. Wertvergleiche
----------------------

Die Operatoren "<", ">", "==", ">=", "<=" und "!=" vergleichen die
Werte zweier Objekte. Die Objekte müssen nicht denselben Typ haben.

In Kapitel Objekte, Werte und Typen heißt es, dass Objekte (neben Typ
und Identität) einen Wert haben. Der Wert eines Objekts ist in Python
ein eher abstrakter Begriff: So gibt es beispielsweise keine
kanonische Zugriffsmethode für den Wert eines Objekts. Außerdem gibt
es keine Vorgabe, dass der Wert eines Objekts auf eine bestimmte Weise
konstruiert sein muss, z. B. aus all seinen Datenattributen bestehen
muss. Vergleichsoperatoren implementieren eine bestimmte Vorstellung
davon, was der Wert eines Objekts ist. Man kann sich vorstellen, dass
sie den Wert eines Objekts indirekt definieren, und zwar durch ihre
Vergleichsimplementierung.

Da alle Typen – direkt oder indirekt – Untertypen von "object" sind,
erben sie das Standardverhalten beim Vergleich von "object". Typen
können dieses Verhalten anpassen, indem sie *erweiterte
Vergleichsmethoden* wie "__lt__()" implementieren, beschrieben unter
Grundlegende Anpassungen.

Das Standardverhalten beim Gleichheitsvergleich ("==" und "!=")
basiert auf der Identität der Objekte. Daher führt der
Gleichheitsvergleich von Instanzen mit derselben Identität zu
Gleichheit, während der Gleichheitsvergleich von Instanzen mit
unterschiedlichen Identitäten zu Ungleichheit führt. Ein Grund für
dieses Standardverhalten ist der Wunsch, dass alle Objekte reflexiv
sein sollen (d.h., "x is y" impliziert "x == y").

Ein Vergleich der Standardreihenfolge ("<", ">", "<=" und ">=") ist
nicht vorgesehen; ein entsprechender Versuch löst einen "TypeError"
aus. Ein Grund für dieses Standardverhalten ist das Fehlen einer
ähnlichen Invarianten wie bei der Gleichheit.

Das Verhalten des standardmäßigen Gleichheitsvergleichs – wonach
Instanzen mit unterschiedlichen Identitäten immer ungleich sind –
steht möglicherweise im Widerspruch zu den Anforderungen von Typen,
die über eine sinnvolle Definition des Objektwerts und der
wertbasierten Gleichheit verfügen. Solche Typen müssen ihr
Vergleichsverhalten anpassen, und tatsächlich haben dies bereits eine
Reihe von integrierten Typen getan.

Die folgende Liste beschreibt das Vergleichsverhalten der wichtigsten
integrierten Datentypen.

* Zahlen der integrierten numerischen Typen (Numerische Typen --- int,
  float, complex) sowie der Standardbibliotheks-Typen
  "fractions.Fraction" und "decimal.Decimal" können sowohl innerhalb
  ihres jeweiligen Typs als auch typübergreifend verglichen werden,
  mit der Einschränkung, dass komplexe Zahlen keinen
  Reihenfolgevergleich zulassen. Innerhalb der Grenzen der beteiligten
  Typen erfolgt der Vergleich mathematisch (algorithmisch) korrekt und
  ohne Genauigkeitsverlust.

  Die Nicht-Zahlen-Werte "float('NaN')" und "decimal.Decimal('NaN')"
  sind Sonderfälle. Jeder geordnete Vergleich einer Zahl mit einem
  Nicht-Zahlen-Wert ergibt „falsch“. Eine kontraintuitive Folge davon
  ist, dass Nicht-Zahlen-Werte nicht mit sich selbst gleich sind.
  Beispielsweise sind die Aussagen "x = float('NaN')" , "3 < x" , "x <
  3" und "x == x" alle falsch, während "x != x" wahr ist. Dieses
  Verhalten entspricht dem IEEE 754-Standard.

* "None" und "NotImplemented" sind Singletons. **PEP 8** empfiehlt,
  Vergleiche bei Singletons stets mit "is" oder "is not"
  durchzuführen, niemals mit den Gleichheitsoperatoren.

* Binary sequences (instances of "bytes" or "bytearray") can be
  compared within and across their types.  They compare
  lexicographically using the numeric values of their elements.

* Zeichenketten (Instanzen von "str") werden lexikografisch anhand der
  numerischen Unicode-Codepunkte (das Ergebnis der integrierten
  Funktion "ord()") ihrer Zeichen verglichen. [3]

  Zeichenketten und Binärsequenzen lassen sich nicht direkt
  miteinander vergleichen.

* Sequenzen (Instanzen von "tuple", "list" oder "range") können nur
  innerhalb ihres jeweiligen Typs verglichen werden, wobei zu beachten
  ist, dass Bereiche keinen Reihenfolgevergleich unterstützen. Ein
  Gleichheitsvergleich zwischen diesen Typen führt zu Ungleichheit,
  und ein Reihenfolgevergleich zwischen diesen Typen löst eine
  "TypeError" aus.

  Sequenzen werden lexikografisch verglichen, indem die entsprechenden
  Elemente miteinander verglichen werden. Die integrierten Container
  gehen in der Regel davon aus, dass identische Objekte mit sich
  selbst gleich sind. Dadurch können sie Gleichheitsprüfungen für
  identische Objekte überspringen, um die Leistung zu verbessern und
  ihre internen Invarianten aufrechtzuerhalten.

  Der lexikografische Vergleich zwischen den integrierten Sammlungen
  funktioniert wie folgt:

  * Damit zwei Sammlungen als gleich angesehen werden können, müssen
    sie denselben Typ und dieselbe Länge haben, und jedes Paar
    entsprechender Elemente muss als gleich erkannt werden
    (beispielsweise ist "[1,2] == (1,2)" falsch, da der Typ nicht
    derselbe ist).

  * Sammlungen, die den Vergleich von Reihenfolgen unterstützen,
    werden genauso geordnet wie ihr erstes ungleiches Element
    (beispielsweise hat "[1,2,x] <= [1,2,y]" denselben Wert wie "x <=
    y"). Wenn kein entsprechendes Element vorhanden ist, wird die
    kürzere Sammlung zuerst geordnet (beispielsweise ist "[1,2] <
    [1,2,3]" wahr).

* Mappings (Instanzen von "dict") sind genau dann gleich, wenn sie
  gleiche "(key, value)"-Paare aufweisen. Der Gleichheitsvergleich der
  Schlüssel und Werte gewährleistet Reflexivität.

  Auftragsvergleiche ("<", ">", "<=" und ">=") lösen den Fehler
  "TypeError" aus.

* Mengen (Instanzen von "set" oder "frozenset") können sowohl
  innerhalb ihres Typs als auch typübergreifend verglichen werden.

  Sie definieren Ordnungsvergleichsoperatoren als Tests auf
  Teilmengen- und Übermengenbeziehungen. Diese Relationen definieren
  keine Gesamtordnungen (beispielsweise sind die beiden Mengen "{1,2}"
  und "{2,3}" weder gleich, noch sind sie Teilmengen voneinander, noch
  sind sie Übermengen voneinander). Dementsprechend sind Mengen keine
  geeigneten Argumente für Funktionen, die von einer totalen Ordnung
  abhängen (beispielsweise liefern "min()", "max()" und "sorted()"
  undefinierte Ergebnisse, wenn eine Liste von Mengen als Eingabe
  gegeben wird).

  Der Vergleich von Mengen bedingt die Reflexivität ihrer Elemente.

* Für die meisten anderen integrierten Typen sind keine
  Vergleichsmethoden implementiert, sodass sie das
  Standardvergleichsverhalten übernehmen.

Benutzerdefinierte Klassen, die ihr Vergleichsverhalten anpassen,
sollten nach Möglichkeit bestimmte Konsistenzregeln befolgen:

* Der Gleichheitsvergleich sollte reflexiv sein. Mit anderen Worten:
  Identische Objekte sollten als gleich angesehen werden:

     "x is y" bedeutet "x == y"

* Der Vergleich sollte symmetrisch sein. Mit anderen Worten: Die
  folgenden Ausdrücke sollten zum gleichen Ergebnis führen:

     "x == y" und "y == x"

     "x != y" und "y != x"

     "x < y" und "y > x"

     "x <= y" und "y >= x"

* Die Vergleichbarkeit sollte transitiv sein. Die folgenden (nicht
  erschöpfenden) Beispiele veranschaulichen dies:

     "x > y and y > z" bedeutet "x > z"

     "x < y and y <= z" bedeutet "x < z"

* Ein inverser Vergleich sollte zur booleschen Negation führen. Mit
  anderen Worten: Die folgenden Ausdrücke sollten dasselbe Ergebnis
  liefern:

     "x == y" und "not x != y"

     "x < y" und "not x >= y" (zum Thema Gesamtordnung)

     "x > y" und "not x <= y" (zum Thema Gesamtordnung)

  Die letzten beiden Ausdrücke gelten für vollständig geordnete Mengen
  (z. B. für Folgen, jedoch nicht für Mengen oder Abbildungen). Siehe
  auch den Dekorator  "@~functools.total_ordering" .

* Das Ergebnis von "hash()" sollte mit der Gleichheit übereinstimmen.
  Objekte, die gleich sind, sollten entweder denselben Hash-Wert haben
  oder als "unhashable“ gekennzeichnet sein.

Python erzwingt diese Konsistenzregeln nicht. Tatsächlich sind die
„Not-a-Number“-Werte ein Beispiel dafür, dass diese Regeln nicht
befolgt werden.


6.10.2. Testbetrieb der Mitgliedschaft
--------------------------------------

Die Operatoren "in" und "not in" prüfen auf Zugehörigkeit. "x in s"
ergibt "True", wenn *x* zu *s* gehört, und andernfalls "False". "x not
in s" gibt die Negation von "x in s" zurück. Alle integrierten
Sequenzen und Mengen-Typen unterstützen dies ebenso wie Wörterbücher,
bei denen "in" prüft, ob das Wörterbuch einen bestimmten Schlüssel
enthält. Bei Containertypen wie *list*, *tuple*, *set*, *frozenset*,
*dict* oder *collections.deque* ist der Ausdruck ` "x in y" `
gleichbedeutend mit ` "any(x is e or x == e for e in y)`".

Bei den Typen "String“ und "Bytes“ gilt: "x in y" ist genau dann
"True" , wenn *x* ein Teilstring von *y* ist. Ein gleichwertiger Test
ist "y.find(x) != -1" . Leere Strings gelten immer als Teilstring
jedes anderen Strings, daher gibt """ in "abc"" den Wert "True"
zurück.

Bei benutzerdefinierten Klassen, die die Methode "__contains__()"
definieren, gibt  "x in y"  den Wert  "True"  zurück, wenn
"y.__contains__(x)"  einen wahren Wert zurückgibt, und andernfalls den
Wert  "False" .

Bei benutzerdefinierten Klassen, die "__contains__()" nicht
definieren, wohl aber "__iter__()", ist "x in y" genau dann "True",
wenn beim Iterieren über "y" ein Wert "z" geliefert wird, für den der
Ausdruck "x is z or x == z" wahr ist. Wird während der Iteration eine
Ausnahme ausgelöst, verhält es sich so, als hätte "in" diese Ausnahme
ausgelöst.

Zuletzt wird das alte Iterationsprotokoll versucht: Definiert eine
Klasse "__getitem__()", ist "x in y" genau dann "True", wenn es einen
nicht negativen ganzzahligen Index *i* gibt, für den "x is y[i] or x
== y[i]" gilt, und kein kleinerer ganzzahliger Index die Ausnahme
"IndexError" auslöst. (Wird eine andere Ausnahme ausgelöst, verhält es
sich so, als hätte "in" diese Ausnahme ausgelöst.)

Der Operator "not in" ist so definiert, dass er den umgekehrten
Wahrheitswert von "in" hat.


6.10.3. Identitätsvergleiche
----------------------------

Die Operatoren "is" und "is not" prüfen die Identität eines Objekts:
"x is y" ist genau dann wahr, wenn *x* und *y* dasselbe Objekt sind.
Die Identität eines Objekts wird mithilfe der Funktion "id()"
ermittelt. "x is not y" liefert den umgekehrten Wahrheitswert. [4]


6.11. Boolesche Operationen
===========================

   or_test  ::= and_test | or_test "or" and_test
   and_test ::= not_test | and_test "and" not_test
   not_test ::= comparison | "not" not_test

Im Zusammenhang mit booleschen Operationen sowie bei der Verwendung
von Ausdrücken in Anweisungen zur Kontrollflusssteuerung werden die
folgenden Werte als „falsch“ interpretiert: "False" , "None" , die
numerische Null aller Typen sowie leere Zeichenketten und Container
(einschließlich Zeichenketten, Tupel, Listen, Wörterbücher, Mengen und
„frozensets“). Alle anderen Werte werden als "wahr“ interpretiert.
Benutzerdefinierte Objekte können ihren Wahrheitswert anpassen, indem
sie eine Methode ` "__bool__()" ` bereitstellen.

Der Operator "not" liefert „ "True" “, wenn sein Argument falsch ist,
andernfalls "False" .

Der Ausdruck "x and y" wertet zunächst *x* aus; ist *x* falsch, wird
dessen Wert zurückgegeben; andernfalls wird *y* ausgewertet und der
resultierende Wert zurückgegeben.

Der Ausdruck "x or y" wertet zunächst *x* aus; ist *x* wahr, wird
dessen Wert zurückgegeben; andernfalls wird *y* ausgewertet und der
resultierende Wert zurückgegeben.

Beachten Sie, dass weder "and" noch "or" den Wert und den Typ, den sie
zurückgeben, auf "False" und "True" beschränken, sondern vielmehr das
zuletzt ausgewertete Argument zurückgeben. Dies ist manchmal nützlich,
z. B. wenn "s" eine Zeichenkette ist, die durch einen Standardwert
ersetzt werden soll, falls sie leer ist; in diesem Fall liefert der
Ausdruck "s or 'foo'" den gewünschten Wert. Da "not" einen neuen Wert
erzeugen muss, gibt es unabhängig vom Typ seines Arguments einen
booleschen Wert zurück (beispielsweise erzeugt "not 'foo'" "False"
statt "''" ).


6.12. Zuweisungsausdrücke
=========================

   assignment_expression ::= [identifier ":="] expression

Ein Zuweisungsausdruck (manchmal auch als "benannter Ausdruck“ oder
"Walrus“ bezeichnet) weist einem "identifier" eine "expression" zu und
gibt gleichzeitig den Wert des "expression" zurück.

Ein häufiger Anwendungsfall ist die Verarbeitung von übereinstimmenden
regulären Ausdrücken:

   if matching := pattern.search(data):
       do_something(matching)

Oder bei der Verarbeitung eines Dateistroms in Blöcken:

   while chunk := file.read(9000):
       process(chunk)

Zuweisungsausdrücke müssen in Klammern gesetzt werden, wenn sie als
Ausdrucksanweisungen verwendet werden oder als Unterausdrücke in
Slicing-, Bedingungs-, Lambda-, Schlüsselwort-Argument- und
Comprehension-if-Ausdrücken sowie in den Anweisungen "assert" , "with"
und "assignment" . An allen anderen Stellen, an denen sie verwendet
werden können, sind Klammern nicht erforderlich, einschließlich in den
Anweisungen "if" und "while" .

Added in version 3.8: Weitere Informationen zu Zuweisungsausdrücken
finden Sie unter **PEP 572**.


6.13. Bedingte Ausdrücke
========================

   conditional_expression ::= or_test ["if" or_test "else" expression]
   expression             ::= conditional_expression | lambda_expr

Ein bedingter Ausdruck (manchmal auch als „ternärer Operator“
bezeichnet) ist eine Alternative zur if-else-Anweisung. Da es sich um
einen Ausdruck handelt, gibt er einen Wert zurück und kann als
Teilausdruck auftreten.

Der Ausdruck "x if C else y" wertet zunächst die Bedingung *C* und
nicht *x* aus. Ist *C* wahr, wird *x* ausgewertet und dessen Wert
zurückgegeben; andernfalls wird *y* ausgewertet und dessen Wert
zurückgegeben.

Weitere Informationen zu bedingten Ausdrücken finden Sie unter **PEP
308**.


6.14. Lambdas
=============

   lambda_expr ::= "lambda" [parameter_list] ":" expression

Lambda expressions (sometimes called lambda forms) are used to create
anonymous functions. The expression "lambda parameters: expression"
yields a function object.  The unnamed object behaves like a function
object defined with:

   def <lambda>(parameters):
       return expression

Informationen zur Syntax von Parameterlisten finden Sie im Abschnitt
Funktionsdefinitionen . Beachten Sie, dass mit Lambda-Ausdrücken
erstellte Funktionen keine Anweisungen oder Anmerkungen enthalten
dürfen.


6.15. Ausdruckslisten
=====================

   starred_expression       ::= ["*"] or_expr
   flexible_expression      ::= assignment_expression | starred_expression
   flexible_expression_list ::= flexible_expression ("," flexible_expression)* [","]
   starred_expression_list  ::= starred_expression ("," starred_expression)* [","]
   expression_list          ::= expression ("," expression)* [","]
   yield_list               ::= expression_list | starred_expression "," [starred_expression_list]

Sofern sie nicht Teil einer Listen- oder Mengenausgabe ist, ergibt
eine Ausdrucksliste, die mindestens ein Komma enthält, ein Tupel. Die
Länge des Tupels entspricht der Anzahl der Ausdrücke in der Liste. Die
Ausdrücke werden von links nach rechts ausgewertet.

Ein Sternchen "*" bezeichnet *iterable unpacking*. Sein Operand muss
ein *iterable* sein. Das iterable wird an der Stelle des Unpackings zu
einer Folge von Elementen erweitert, die in das neue Tupel, die neue
Liste oder die neue Menge aufgenommen werden.

Added in version 3.5: Das Entpacken von Iterables in Ausdruckslisten,
ursprünglich vorgeschlagen von **PEP 448**.

Added in version 3.11: Jeder Eintrag in einer Ausdrucksliste kann mit
einem Sternchen versehen werden. Siehe **PEP 646**.

Ein abschließendes Komma ist nur erforderlich, um ein Tupel mit einem
Element zu bilden, wie beispielsweise "1,"; in allen anderen Fällen
ist es optional. Ein einzelner Ausdruck ohne abschließendes Komma
bildet kein Tupel, sondern liefert den Wert dieses Ausdrucks. (Um ein
leeres Tupel zu bilden, verwenden Sie ein leeres Klammerpaar: "()".)


6.16. Bewertungsreihenfolge
===========================

Python wertet Ausdrücke von links nach rechts aus. Beachten Sie, dass
bei der Auswertung einer Zuweisung die rechte Seite vor der linken
Seite ausgewertet wird.

In den folgenden Zeilen werden die Ausdrücke in der arithmetischen
Reihenfolge ihrer Suffixe ausgewertet:

   expr1, expr2, expr3, expr4
   (expr1, expr2, expr3, expr4)
   {expr1: expr2, expr3: expr4}
   expr1 + expr2 * (expr3 - expr4)
   expr1(expr2, expr3, *expr4, **expr5)
   expr3, expr4 = expr1, expr2


6.17. Reihenfolge der Rechenoperatoren
======================================

Die folgende Tabelle fasst die Operatorpriorität in Python zusammen,
von der höchsten Priorität (stärkste Bindung) bis zur niedrigsten
Priorität (schwächste Bindung). Operatoren in derselben Spalte haben
dieselbe Priorität. Sofern die Syntax nicht ausdrücklich angegeben
ist, sind Operatoren binär. Operatoren in derselben Spalte werden von
links nach rechts gruppiert (mit Ausnahme von Potenzierung und
bedingten Ausdrücken, die von rechts nach links gruppiert werden).

Beachten Sie, dass Vergleichsoperatoren, Zugehörigkeitsprüfungen und
Identitätsprüfungen alle dieselbe Priorität haben und eine Verkettung
von links nach rechts aufweisen, wie im Abschnitt Vergleiche
beschrieben.

+-------------------------------------------------+---------------------------------------+
| Operator                                        | Beschreibung                          |
|=================================================|=======================================|
| "(expressions...)",  "[expressions...]", "{key: | Gebundener oder in Klammern gesetzter |
| value...}", "{expressions...}"                  | Ausdruck, Listenanzeige,              |
|                                                 | Wörterbuchanzeige, Mengenanzeige      |
+-------------------------------------------------+---------------------------------------+
| "x[index]", "x[index:index]",                   | Subscription, slicing, call,          |
| "x(arguments...)", "x.attribute"                | attribute reference                   |
+-------------------------------------------------+---------------------------------------+
| "await x"                                       | Ausdruck "Await“                      |
+-------------------------------------------------+---------------------------------------+
| "**"                                            | Potenzieren [5]                       |
+-------------------------------------------------+---------------------------------------+
| "+x", "-x", "~x"                                | Positiv, negativ, bitweises NOT       |
+-------------------------------------------------+---------------------------------------+
| "*", "@", "/", "//", "%"                        | Multiplikation, Matrixmultiplikation, |
|                                                 | Division, Rundung nach unten, Rest    |
|                                                 | [6]                                   |
+-------------------------------------------------+---------------------------------------+
| "+", "-"                                        | Addition und Subtraktion              |
+-------------------------------------------------+---------------------------------------+
| "<<", ">>"                                      | Verschiebungen                        |
+-------------------------------------------------+---------------------------------------+
| "&"                                             | Bitweises UND                         |
+-------------------------------------------------+---------------------------------------+
| "^"                                             | Bitweises XOR                         |
+-------------------------------------------------+---------------------------------------+
| "|"                                             | Bitweises ODER                        |
+-------------------------------------------------+---------------------------------------+
| "in", "not in", "is", "is not", "<", "<=", ">", | Vergleiche, einschließlich            |
| ">=", "!=", "=="                                | Zugehörigkeits- und                   |
|                                                 | Identitätsprüfungen                   |
+-------------------------------------------------+---------------------------------------+
| "nicht x"                                       | Boolesches NOT                        |
+-------------------------------------------------+---------------------------------------+
| "and"                                           | Boolesches UND                        |
+-------------------------------------------------+---------------------------------------+
| "or"                                            | Boolesches OR                         |
+-------------------------------------------------+---------------------------------------+
| "if" -- "else"                                  | Bedingter Ausdruck                    |
+-------------------------------------------------+---------------------------------------+
| "lambda"                                        | Lambda-Ausdruck                       |
+-------------------------------------------------+---------------------------------------+
| ":="                                            | Zuweisungsausdruck                    |
+-------------------------------------------------+---------------------------------------+

-[ Fußnoten ]-

[1] Zwar gilt „ "abs(x%y) < abs(y)" “ mathematisch gesehen, doch bei
    Fließkommazahlen trifft dies aufgrund von Rundungsfehlern
    numerisch möglicherweise nicht zu. Nehmen wir beispielsweise an,
    dass auf einer Plattform, auf der ein Python-Fließkommawert eine
    IEEE-754-Zahl mit doppelter Genauigkeit ist, das berechnete
    Ergebnis „ "-1e-100 + 1e100" “ lautet, damit „ "-1e-100 % 1e100" “
    dasselbe Vorzeichen wie „ "1e100" “ hat; dies entspricht numerisch
    genau „ "1e100" “.  Die Funktion „ "math.fmod()" “ gibt
    stattdessen ein Ergebnis zurück, dessen Vorzeichen mit dem
    Vorzeichen des ersten Arguments übereinstimmt, und liefert in
    diesem Fall daher „ "-1e-100" “. Welcher Ansatz besser geeignet
    ist, hängt von der jeweiligen Anwendung ab.

[2] Wenn x sehr nahe an einem exakten ganzzahligen Vielfachen von y
    liegt, kann es aufgrund von Rundungen vorkommen, dass "x//y" um
    eins größer ist als "(x-x%y)//y". In solchen Fällen gibt Python
    das letztere Ergebnis zurück, damit weiterhin gilt, dass
    "divmod(x,y)[0] * y + x % y" sehr nahe an "x" liegt.

[3] Der Unicode-Standard unterscheidet zwischen *Codepunkten* (z. B.
    U+0041) und *abstrakten Zeichen* (z. B. „LATIN CAPITAL LETTER A“).
    Während die meisten abstrakten Zeichen in Unicode nur durch einen
    einzigen Codepunkt dargestellt werden, gibt es eine Reihe von
    abstrakten Zeichen, die zusätzlich durch eine Folge von mehr als
    einem Codepunkt dargestellt werden können. Beispielsweise kann das
    abstrakte Zeichen „LATIN CAPITAL LETTER C WITH CEDILLA“ als
    einzelnes *vorkomponiertes Zeichen* an der Codeposition U+00C7
    oder als Folge aus einem *Basiszeichen* an der Codeposition U+0043
    (LATIN CAPITAL LETTER C), gefolgt von einem *Kombinationszeichen*
    an der Codeposition U+0327 (COMBINING CEDILLA).

    Die Vergleichsoperatoren für Zeichenketten vergleichen auf der
    Ebene der Unicode-Codepunkte. Dies mag für Menschen zunächst nicht
    intuitiv erscheinen. Beispielsweise ist „ ""\u00C7" ==
    "\u0043\u0327"" “ gleichbedeutend mit „ "False" “, obwohl beide
    Zeichenketten dasselbe abstrakte Zeichen „LATIN CAPITAL LETTER C
    WITH CEDILLA“ darstellen.

    Um Zeichenketten auf der Ebene abstrakter Zeichen zu vergleichen
    (d.h. auf eine für Menschen intuitive Weise), verwenden Sie
    "unicodedata.normalize()".

[4] Aufgrund der automatischen Speicherbereinigung, der Freilisten und
    der dynamischen Natur von Deskriptoren kann es bei bestimmten
    Anwendungen des Operators „ "is" “ – beispielsweise bei
    Vergleichen zwischen Instanzmethoden oder Konstanten – zu
    scheinbar ungewöhnlichem Verhalten kommen. Weitere Informationen
    finden Sie in der entsprechenden Dokumentation.

[5] Der Potenzoperator "**" bindet weniger streng als ein
    arithmetischer oder bitweiser unärer Operator zu seiner Rechten,
    das heißt: "2**-1" ergibt "0.5".

[6] Der Operator „ "%" “ wird ebenfalls zur Formatierung von
    Zeichenketten verwendet; es gilt dieselbe Priorität.
