2. Lexikalische Analyse¶

Ein Python-Programm wird von einem Parser gelesen. Die Eingabe für den Parser ist ein Strom von Tokens, die vom lexikalischen Analysator (auch Tokenizer genannt) erzeugt werden. Dieses Kapitel beschreibt, wie der lexikalische Analysator diese Tokens erzeugt.

Der lexikalische Analysator ermittelt die Kodierung des Programmtextes (standardmäßig UTF-8) und dekodiert den Text in Quellzeichen. Wenn der Text nicht dekodiert werden kann, wird ein SyntaxError ausgelöst.

Anschließend verwendet der lexikalische Analysator die Quellzeichen, um einen Strom von Tokens zu erzeugen. Der Typ eines erzeugten Tokens hängt im Allgemeinen vom nächsten zu verarbeitenden Quellzeichen ab. Ähnlich hängen andere spezielle Verhaltensweisen des Analysators vom ersten Quellzeichen ab, das noch nicht verarbeitet wurde. Die folgende Tabelle gibt eine kurze Zusammenfassung dieser Quellzeichen mit Links zu Abschnitten, die weitere Informationen enthalten.

Zeichen	Nächstes Token (oder andere relevante Dokumentation)
Leerzeichen Tabulator Seitenvorschub	Leerraum
CR, LF	Neue Zeile Einrückung
Backslash (`\`)	Explizites Zeilenverknüpfen (Auch signifikant in String-Escape-Sequenzen)
Raute (`#`)	Kommentar
Anführungszeichen (`'`, `"`)	String-Literal
ASCII-Buchstabe (`a`-`z`, `A`-`Z`) Nicht-ASCII-Zeichen	Name Präfix-String- oder Bytes-Literal
Unterstrich (`_`)	Name (Kann auch Teil von numerischen Literalen sein)
Ziffer (`0`-`9`)	Numerisches Literal
Punkt (`.`)	Numerisches Literal Operator
Fragezeichen (`?`) Dollar (`$`) Backtick (`) Steuerzeichen	Fehler (außerhalb von String-Literalen und Kommentaren)
Anderes druckbares Zeichen	Operator oder Trennzeichen
Dateiende	Endemarker

2.1. Zeilenstruktur¶

Ein Python-Programm ist in eine Anzahl von logischen Zeilen unterteilt.

2.1.1. Logische Zeilen¶

Das Ende einer logischen Zeile wird durch das Token NEWLINE dargestellt. Anweisungen können keine logischen Zeilengrenzen überschreiten, es sei denn, wo NEWLINE durch die Syntax erlaubt ist (z. B. zwischen Anweisungen in zusammengesetzten Anweisungen). Eine logische Zeile wird aus einer oder mehreren physischen Zeilen konstruiert, indem die Regeln für explizites (explicit) oder implizites (implicit) Zeilenverknüpfen befolgt werden.

2.1.2. Physische Zeilen¶

Eine physische Zeile ist eine Zeichensequenz, die durch eine der folgenden Zeilenende-Sequenzen beendet wird:

die Unix-Form mit ASCII LF (Linefeed),
die Windows-Form mit der ASCII-Sequenz CR LF (Carriage Return gefolgt von Linefeed),
die ‘Classic Mac OS’-Form mit dem ASCII CR (Carriage Return) Zeichen.

Unabhängig von der Plattform wird jede dieser Sequenzen durch ein einzelnes ASCII LF (Linefeed)-Zeichen ersetzt. (Dies geschieht auch innerhalb von String-Literalen.) Jede Zeile kann jede der Sequenzen verwenden; sie müssen nicht innerhalb einer Datei konsistent sein.

Das Ende der Eingabe dient auch als impliziter Abschluss für die letzte physische Zeile.

Formell

newline: <ASCII LF> | <ASCII CR> <ASCII LF> | <ASCII CR>

2.1.3. Kommentare¶

Ein Kommentar beginnt mit einem Rautezeichen (#), das nicht Teil eines String-Literals ist, und endet am Ende der physischen Zeile. Ein Kommentar markiert das Ende der logischen Zeile, es sei denn, die Regeln für implizites Zeilenverknüpfen werden angewendet. Kommentare werden von der Syntax ignoriert.

2.1.4. Kodierungsdeklarationen¶

Wenn ein Kommentar in der ersten oder zweiten Zeile des Python-Skripts dem regulären Ausdruck coding[=:]\s*([-\w.]+) entspricht, wird dieser Kommentar als Kodierungsdeklaration verarbeitet; die erste Gruppe dieses Ausdrucks benennt die Kodierung der Quellcodedatei. Die Kodierungsdeklaration muss in einer eigenen Zeile stehen. Wenn es sich um die zweite Zeile handelt, muss die erste Zeile ebenfalls eine reine Kommentarzeile sein. Die empfohlenen Formen eines Kodierungsausdrucks sind

# -*- coding: <encoding-name> -*-

was auch von GNU Emacs erkannt wird, und

# vim:fileencoding=<encoding-name>

was von Bram Moolenaars VIM erkannt wird.

Wenn keine Kodierungsdeklaration gefunden wird, ist die Standardkodierung UTF-8. Wenn die implizite oder explizite Kodierung einer Datei UTF-8 ist, wird eine anfängliche UTF-8 Byte Order Mark (b'\xef\xbb\xbf') ignoriert, anstatt einen Syntaxfehler zu verursachen.

Wenn eine Kodierung deklariert wird, muss der Kodierungsname von Python erkannt werden (siehe Standard-Kodierungen). Die Kodierung wird für die gesamte lexikalische Analyse verwendet, einschließlich String-Literalen, Kommentaren und Bezeichnern.

Die gesamte lexikalische Analyse, einschließlich String-Literalen, Kommentaren und Bezeichnern, arbeitet mit Unicode-Text, der mithilfe der Quellkodierung dekodiert wurde. Jeder Unicode-Codepunkt, außer dem NUL-Steuerzeichen, kann in Python-Quelltext vorkommen.

source_character:  <any Unicode code point, except NUL>

2.1.5. Explizites Zeilenverknüpfen¶

Zwei oder mehr physische Zeilen können mithilfe von Backslash-Zeichen (\) zu logischen Zeilen zusammengefügt werden, wie folgt: Wenn eine physische Zeile mit einem Backslash endet, der nicht Teil eines String-Literals oder Kommentars ist, wird sie mit der folgenden Zeile zu einer einzigen logischen Zeile zusammengefügt, wobei der Backslash und das folgende Zeilenende-Zeichen gelöscht werden. Zum Beispiel

if 1900 < year < 2100 and 1 <= month <= 12 \
   and 1 <= day <= 31 and 0 <= hour < 24 \
   and 0 <= minute < 60 and 0 <= second < 60:   # Looks like a valid date
        return 1

Eine Zeile, die mit einem Backslash endet, kann keinen Kommentar tragen. Ein Backslash setzt keinen Kommentar fort. Ein Backslash setzt keinen Token fort, außer bei String-Literalen (d. h., Tokens außer String-Literalen können nicht mit einem Backslash über physische Zeilen hinweg aufgeteilt werden). Ein Backslash ist an anderer Stelle auf einer Zeile außerhalb eines String-Literals illegal.

2.1.6. Implizites Zeilenverknüpfen¶

Ausdrücke in Klammern, eckigen Klammern oder geschweiften Klammern können über mehr als eine physische Zeile ohne Backslashes aufgeteilt werden. Zum Beispiel

month_names = ['Januari', 'Februari', 'Maart',      # These are the
               'April',   'Mei',      'Juni',       # Dutch names
               'Juli',    'Augustus', 'September',  # for the months
               'Oktober', 'November', 'December']   # of the year

Implizit fortgesetzte Zeilen können Kommentare enthalten. Die Einrückung der Fortsetzungszeilen ist nicht wichtig. Leer fortgesetzte Zeilen sind erlaubt. Es gibt kein NEWLINE-Token zwischen implizit fortgesetzten Zeilen. Implizit fortgesetzte Zeilen können auch innerhalb von dreifach zitierten Strings vorkommen (siehe unten); in diesem Fall können sie keine Kommentare tragen.

2.1.7. Leerzeilen¶

Eine logische Zeile, die nur Leerzeichen, Tabulatoren, Seitenvorschübe und möglicherweise einen Kommentar enthält, wird ignoriert (d. h., es wird kein NEWLINE-Token erzeugt). Während der interaktiven Eingabe von Anweisungen kann die Handhabung einer Leerzeile je nach Implementierung der Read-Eval-Print-Schleife variieren. Im Standard-Interpreters werden eine vollständig leere logische Zeile (d. h. eine, die nicht einmal Leerzeichen oder einen Kommentar enthält) verwendet, um eine mehrzeilige Anweisung zu beenden.

2.1.8. Einrückung¶

Führende Leerraumzeichen (Leerzeichen und Tabulatoren) am Anfang einer logischen Zeile werden verwendet, um die Einrückungsebene der Zeile zu berechnen, die wiederum zur Bestimmung der Gruppierung von Anweisungen dient.

Tabulatoren werden (von links nach rechts) durch ein bis acht Leerzeichen ersetzt, sodass die Gesamtzahl der Zeichen bis einschließlich der Ersetzung ein Vielfaches von acht ist (dies soll dieselbe Regel sein wie unter Unix). Die Gesamtzahl der Leerzeichen vor dem ersten Nicht-Leerzeichen bestimmt dann die Einrückung der Zeile. Einrückungen können nicht mit Backslashes über mehrere physische Zeilen hinweg aufgeteilt werden; der Leerraum bis zum ersten Backslash bestimmt die Einrückung.

Einrückungen werden als inkonsistent abgelehnt, wenn eine Quelldatei Tabs und Leerzeichen auf eine Weise mischt, die die Bedeutung vom Wert eines Tabs in Leerzeichen abhängig macht; in diesem Fall wird ein TabError ausgelöst.

Hinweis zur plattformübergreifenden Kompatibilität: Aufgrund der Natur von Texteditoren auf Nicht-UNIX-Plattformen ist es unklug, eine Mischung aus Leerzeichen und Tabs für die Einrückung in einer einzigen Quelldatei zu verwenden. Es sollte auch beachtet werden, dass verschiedene Plattformen die maximale Einrückungsebene explizit einschränken können.

Ein Seitenvorschubzeichen kann am Anfang der Zeile vorhanden sein; es wird für die Einrückungsberechnungen oben ignoriert. Seitenvorschubzeichen, die sich an anderer Stelle im führenden Leerraum befinden, haben eine undefinierte Wirkung (z. B. können sie die Leerzeichenzahl auf Null zurücksetzen).

Die Einrückungsebenen aufeinanderfolgender Zeilen werden verwendet, um INDENT- und DEDENT-Tokens mithilfe eines Stacks wie folgt zu erzeugen:

Vor dem Lesen der ersten Zeile der Datei wird eine einzelne Null auf den Stack gelegt; diese wird niemals wieder entfernt. Die auf den Stack gelegten Zahlen werden immer streng von unten nach oben ansteigen. Zu Beginn jeder logischen Zeile wird die Einrückungsebene der Zeile mit der Oberseite des Stacks verglichen. Wenn sie gleich ist, passiert nichts. Wenn sie größer ist, wird sie auf den Stack gelegt, und ein INDENT-Token wird erzeugt. Wenn sie kleiner ist, muss es eine der auf dem Stack vorhandenen Zahlen sein; alle Zahlen auf dem Stack, die größer sind, werden entfernt, und für jede entfernte Zahl wird ein DEDENT-Token erzeugt. Am Ende der Datei wird für jede Zahl, die auf dem Stack verbleibt und größer als Null ist, ein DEDENT-Token erzeugt.

Hier ist ein Beispiel für ein korrekt (wenn auch verwirrend) eingerücktes Stück Python-Code

def perm(l):
        # Compute the list of all permutations of l
    if len(l) <= 1:
                  return [l]
    r = []
    for i in range(len(l)):
             s = l[:i] + l[i+1:]
             p = perm(s)
             for x in p:
              r.append(l[i:i+1] + x)
    return r

Das folgende Beispiel zeigt verschiedene Einrückungsfehler

 def perm(l):                       # error: first line indented
for i in range(len(l)):             # error: not indented
    s = l[:i] + l[i+1:]
        p = perm(l[:i] + l[i+1:])   # error: unexpected indent
        for x in p:
                r.append(l[i:i+1] + x)
            return r                # error: inconsistent dedent

(Tatsächlich werden die ersten drei Fehler vom Parser erkannt; nur der letzte Fehler wird vom lexikalischen Analysator gefunden — die Einrückung von return r stimmt nicht mit einer vom Stack entfernten Ebene überein.)

2.1.9. Leerraum zwischen Tokens¶

Mit Ausnahme des Anfangs einer logischen Zeile oder in String-Literalen können die Leerraumzeichen Leerzeichen, Tabulator und Seitenvorschub austauschbar verwendet werden, um Tokens zu trennen. Leerraum ist nur zwischen zwei Tokens erforderlich, wenn ihre Verkettung sonst als anderes Token interpretiert werden könnte. Zum Beispiel ist ab ein Token, aber a b sind zwei Tokens. Allerdings ergeben +a und + a beide zwei Tokens, + und a, da +a kein gültiges Token ist.

2.1.10. Endemarker¶

Am Ende der nicht-interaktiven Eingabe erzeugt der lexikalische Analysator ein ENDMARKER-Token.

2.2. Andere Tokens¶

Neben NEWLINE, INDENT und DEDENT gibt es folgende Kategorien von Tokens: Bezeichner und Schlüsselwörter (NAME), Literale (wie NUMBER und STRING) und andere Symbole (Operatoren und Trennzeichen, OP). Leerraumzeichen (außer den zuvor erwähnten logischen Zeilenabschlüssen) sind keine Tokens, sondern dienen zur Abgrenzung von Tokens. Wo Mehrdeutigkeit besteht, bildet ein Token den längstmöglichen String, der beim Lesen von links nach rechts einen legalen Token bildet.

2.3. Namen (Bezeichner und Schlüsselwörter)¶

NAME-Tokens repräsentieren Bezeichner, Schlüsselwörter und weiche Schlüsselwörter.

Innerhalb des ASCII-Bereichs (U+0001..U+007F) umfassen die gültigen Zeichen für Namen die Groß- und Kleinbuchstaben (A-Z und a-z), den Unterstrich _ und, außer beim ersten Zeichen, die Ziffern 0 bis 9.

Namen müssen mindestens ein Zeichen enthalten, haben aber keine obere Längenbegrenzung. Die Groß-/Kleinschreibung ist bedeutsam.

Zusätzlich zu A-Z, a-z, _ und 0-9 können Namen auch „buchstabenähnliche“ und „zahlähnliche“ Zeichen außerhalb des ASCII-Bereichs verwenden, wie nachstehend detailliert beschrieben.

Alle Bezeichner werden beim Parsen in die Normalisierungsform NFKC umgewandelt; der Vergleich von Bezeichnern basiert auf NFKC.

Formell muss das erste Zeichen eines normalisierten Bezeichners zur Menge id_start gehören, die die Vereinigung von

Unicode-Kategorie <Lu> - Großbuchstaben (einschließlich A bis Z)
Unicode-Kategorie <Ll> - Kleinbuchstaben (einschließlich a bis z)
Unicode-Kategorie <Lt> - Titelbuchstaben
Unicode-Kategorie <Lm> - Modifikatorbuchstaben
Unicode-Kategorie <Lo> - andere Buchstaben
Unicode-Kategorie <Nl> - Buchstabenzahlen
{"_"} - der Unterstrich
<Other_ID_Start> - eine explizite Menge von Zeichen in PropList.txt zur Unterstützung der Abwärtskompatibilität

Die übrigen Zeichen müssen zur Menge id_continue gehören, die die Vereinigung von

allen Zeichen in id_start
Unicode-Kategorie <Nd> - Dezimalzahlen (einschließlich 0 bis 9)
Unicode-Kategorie <Pc> - Verbinder-Interpunktion
Unicode-Kategorie <Mn> - nicht-abstandshaltende Zeichen
Unicode-Kategorie <Mc> - abstandhaltende kombinierende Zeichen
<Other_ID_Continue> - eine weitere explizite Menge von Zeichen in PropList.txt zur Unterstützung der Abwärtskompatibilität

Unicode-Kategorien verwenden die Version der Unicode Character Database, wie sie im Modul unicodedata enthalten ist.

Diese Mengen basieren auf dem Unicode Standard Annex UAX-31. Siehe auch PEP 3131 für weitere Details.

Noch formeller sind Namen durch die folgenden lexikalischen Definitionen beschrieben

NAME:         xid_start xid_continue*
id_start:     <Lu> | <Ll> | <Lt> | <Lm> | <Lo> | <Nl> | "_" | <Other_ID_Start>
id_continue:  id_start | <Nd> | <Pc> | <Mn> | <Mc> | <Other_ID_Continue>
xid_start:    <all characters in id_start whose NFKC normalization is
               in (id_start xid_continue*)">
xid_continue: <all characters in id_continue whose NFKC normalization is
               in (id_continue*)">
identifier:   <NAME, except keywords>

Eine nicht-normative Auflistung aller gültigen Bezeichnerzeichen gemäß Unicode ist in der Datei DerivedCoreProperties.txt in der Unicode Character Database verfügbar.

2.3.1. Schlüsselwörter¶

Die folgenden Namen sind reservierte Wörter oder Schlüsselwörter der Sprache und können nicht als normale Bezeichner verwendet werden. Sie müssen exakt so geschrieben werden, wie sie hier stehen:

False      await      else       import     pass
None       break      except     in         raise
True       class      finally    is         return
and        continue   for        lambda     try
as         def        from       nonlocal   while
assert     del        global     not        with
async      elif       if         or         yield

2.3.2. Weiche Schlüsselwörter¶

Hinzugefügt in Version 3.10.

Einige Namen sind nur in bestimmten Kontexten reserviert. Diese werden als weiche Schlüsselwörter bezeichnet

match, case und _, wenn sie in der match-Anweisung verwendet werden.
type, wenn sie in der type-Anweisung verwendet werden.

Diese fungieren syntaktisch als Schlüsselwörter in ihren spezifischen Kontexten, aber diese Unterscheidung wird auf der Parser-Ebene getroffen, nicht beim Tokenisieren.

Als weiche Schlüsselwörter ist ihre Verwendung in der Grammatik möglich, während die Kompatibilität mit vorhandenem Code, der diese Namen als Bezeichner verwendet, erhalten bleibt.

Geändert in Version 3.12: type ist jetzt ein weiches Schlüsselwort.

2.3.3. Reservierte Bezeichnerklassen¶

Bestimmte Klassen von Bezeichnern (außer Schlüsselwörtern) haben spezielle Bedeutungen. Diese Klassen werden durch die Muster von führenden und nachgestellten Unterstrichzeichen identifiziert:

_*

Nicht importiert von from module import *.

_

In einem case-Muster innerhalb einer match-Anweisung ist _ ein weiches Schlüsselwort, das einen Platzhalter bezeichnet.

Getrennt davon macht der interaktive Interpreter das Ergebnis der letzten Auswertung in der Variable _ verfügbar. (Es wird im Modul builtins gespeichert, neben integrierten Funktionen wie print.)

Ansonsten ist _ ein regulärer Bezeichner. Er wird oft verwendet, um „besondere“ Elemente zu benennen, ist aber für Python selbst nicht besonders.

Hinweis

Der Name _ wird oft in Verbindung mit Internationalisierung verwendet; siehe die Dokumentation für das Modul gettext für weitere Informationen zu dieser Konvention.

Er wird auch häufig für ungenutzte Variablen verwendet.

__*__

Systemdefinierte Namen, informell als „dunder“-Namen bekannt. Diese Namen werden vom Interpreter und seiner Implementierung (einschließlich der Standardbibliothek) definiert. Aktuelle Systemnamen werden im Abschnitt Spezielle Methodennamen und an anderer Stelle besprochen. In zukünftigen Versionen von Python werden wahrscheinlich weitere definiert. Jede Verwendung von __*__-Namen, in irgendeinem Kontext, die nicht einer explizit dokumentierten Verwendung folgt, kann ohne Vorwarnung brechen.

__*

Klasseninterne Namen. Namen in dieser Kategorie, wenn sie im Kontext einer Klassendefinition verwendet werden, werden in eine mangled Form umgeschrieben, um Namenskonflikte zwischen „privaten“ Attributen von Basis- und abgeleiteten Klassen zu vermeiden. Siehe Abschnitt Bezeichner (Namen).

2.4. Literale¶

Literale sind Notationen für konstante Werte bestimmter integrierter Typen.

Im Hinblick auf die lexikalische Analyse hat Python String-, Bytes- und numerische Literale.

Andere „Literale“ werden lexikalisch durch Schlüsselwörter (None, True, False) und das spezielle Ellipsen-Token (...) bezeichnet.

2.5. String- und Bytesliterale¶

String-Literale sind Text, der in einfache Anführungszeichen (') oder doppelte Anführungszeichen (") eingeschlossen ist. Zum Beispiel

"spam"
'eggs'

Das Anführungszeichen, das zum Beginn des Literals verwendet wird, beendet es auch, so dass ein String-Literal nur das andere Anführungszeichen enthalten kann (außer bei Escape-Sequenzen, siehe unten). Zum Beispiel

'Say "Hello", please.'
"Don't do that!"

Mit Ausnahme dieser Einschränkung hat die Wahl des Anführungszeichens (' oder ") keine Auswirkungen darauf, wie das Literal geparst wird.

Innerhalb eines String-Literals führt der Backslash (\) eine *Escape-Sequenz* ein, die je nach Zeichen nach dem Backslash eine besondere Bedeutung hat. Zum Beispiel bezeichnet \" das doppelte Anführungszeichen und beendet den String *nicht*.

>>> print("Say \"Hello\" to everyone!")
Say "Hello" to everyone!

Eine vollständige Liste solcher Sequenzen und weitere Details finden Sie weiter unten unter Escape-Sequenzen.

2.5.1. Dreifach Anführungszeichen-Strings¶

Strings können auch in passenden Gruppen von drei einfachen oder doppelten Anführungszeichen eingeschlossen werden. Diese werden im Allgemeinen als *Strings mit dreifachen Anführungszeichen* bezeichnet.

"""This is a triple-quoted string."""

In Literalen mit dreifachen Anführungszeichen sind unescaped Anführungszeichen erlaubt (und werden beibehalten), mit der Ausnahme, dass drei unescaped Anführungszeichen hintereinander das Literal beenden, wenn sie von der gleichen Art sind (' oder "), die am Anfang verwendet wurde.

"""This string has "quotes" inside."""

Unescaped Zeilenumbrüche sind ebenfalls erlaubt und werden beibehalten.

'''This triple-quoted string
continues on the next line.'''

2.5.2. String-Präfixe¶

String-Literale können ein optionales *Präfix* haben, das beeinflusst, wie der Inhalt des Literals geparst wird, zum Beispiel:

b"data"
f'{result=}'

Die erlaubten Präfixe sind:

b: Byte-Literal
r: Raw-String
f: Formatiertes String-Literal („f-String“)
t: Template-String-Literal („t-String“)
u: Keine Auswirkung (erlaubt für Abwärtskompatibilität)

Details zu jedem Typ finden Sie in den verlinkten Abschnitten.

Präfixe sind nicht case-sensitiv (z. B. funktioniert 'B' genauso wie 'b'). Das Präfix 'r' kann mit 'f', 't' oder 'b' kombiniert werden, sodass 'fr', 'rf', 'tr', 'rt', 'br' und 'rb' ebenfalls gültige Präfixe sind.

Hinzugefügt in Version 3.3: Das Präfix 'rb' für Raw-Byte-Literale wurde als Synonym für 'br' hinzugefügt.

Die Unterstützung für das Unicode-Legacy-Literal (u'Wert') wurde wieder eingeführt, um die Wartung von dualen Python 2.x- und 3.x-Codebasen zu vereinfachen. Weitere Informationen finden Sie in PEP 414.

2.5.3. Formale Grammatik¶

String-Literale, mit Ausnahme von „f-Strings“ und „t-Strings“, werden durch die folgenden lexikalischen Definitionen beschrieben.

Diese Definitionen verwenden *negative Lookaheads* (!), um anzuzeigen, dass ein schließendes Anführungszeichen das Literal beendet.

STRING:          [stringprefix] (stringcontent)
stringprefix:    <("r" | "u" | "b" | "br" | "rb"), case-insensitive>
stringcontent:
   | "'''" ( !"'''" longstringitem)* "'''"
   | '"""' ( !'"""' longstringitem)* '"""'
   | "'" ( !"'" stringitem)* "'"
   | '"' ( !'"' stringitem)* '"'
stringitem:      stringchar | stringescapeseq
stringchar:      <any source_character, except backslash and newline>
longstringitem:  stringitem | newline
stringescapeseq: "\" <any source_character>

Beachten Sie, dass wie in allen lexikalischen Definitionen Leerzeichen wichtig sind. Insbesondere muss dem Präfix (falls vorhanden) unmittelbar das startende Anführungszeichen folgen.

2.5.4. Escape-Sequenzen¶

Sofern kein Präfix 'r' oder 'R' vorhanden ist, werden Escape-Sequenzen in Zeichenketten- und Byte-Literalen nach Regeln interpretiert, die denen von Standard-C ähneln. Die erkannten Escape-Sequenzen sind:

Escape-Sequenz	Bedeutung
`\`<Zeilenumbruch>	Ignorierter Zeilenende
`\\`	Backslash
`\'`	Einfaches Anführungszeichen
`\"`	Doppeltes Anführungszeichen
`\a`	ASCII Bell (BEL)
`\b`	ASCII Backspace (BS)
`\f`	ASCII Formfeed (FF)
`\n`	ASCII Linefeed (LF)
`\r`	ASCII Carriage Return (CR)
`\t`	ASCII Horizontal Tab (TAB)
`\v`	ASCII Vertical Tab (VT)
`\<i>ooo</i>`	Oktales Zeichen
`\x<i>hh</i>`	Hexadezimales Zeichen
`\N{<i>name</i>}`	Benanntes Unicode-Zeichen
`\u<i>xxxx</i>`	Hexadezimales Unicode-Zeichen
`\U<i>xxxxxxxx</i>`	Hexadezimales Unicode-Zeichen

2.5.4.1. Ignorierter Zeilenende¶

Ein Backslash kann am Ende einer Zeile hinzugefügt werden, um den Zeilenumbruch zu ignorieren.

>>> 'This string will not include \
... backslashes or newline characters.'
'This string will not include backslashes or newline characters.'

Das gleiche Ergebnis kann durch die Verwendung von Strings mit dreifachen Anführungszeichen oder Klammern und String-Literal-Verkettung erzielt werden.

2.5.4.2. Escaped-Zeichen¶

Um einen Backslash in einem nicht-Raw-Python-String-Literal einzufügen, muss er verdoppelt werden. Die Escape-Sequenz \\ bezeichnet ein einzelnes Backslash-Zeichen.

>>> print('C:\\Program Files')
C:\Program Files

Ebenso bezeichnen die Sequenzen \' und \" das einfache bzw. das doppelte Anführungszeichen.

>>> print('\' and \"')
' and "

2.5.4.3. Oktales Zeichen¶

Die Sequenz \ooo bezeichnet ein *Zeichen* mit dem oktalen (Basis 8) Wert ooo.

>>> '\120'
'P'

Bis zu drei Oktalziffern (0 bis 7) werden akzeptiert.

In einem Byte-Literal bedeutet *Zeichen* ein *Byte* mit dem gegebenen Wert. In einem String-Literal bedeutet es ein Unicode-Zeichen mit dem gegebenen Wert.

Geändert in Version 3.11: Oktale Escapes mit einem Wert größer als 0o377 (255) erzeugen eine DeprecationWarning.

Geändert in Version 3.12: Oktale Escapes mit einem Wert größer als 0o377 (255) erzeugen eine SyntaxWarning. In einer zukünftigen Python-Version werden sie einen SyntaxError auslösen.

2.5.4.4. Hexadezimales Zeichen¶

Die Sequenz \xhh bezeichnet ein *Zeichen* mit dem hexadezimalen (Basis 16) Wert hh.

>>> '\x50'
'P'

Im Gegensatz zu Standard-C sind genau zwei Hexadezimalziffern erforderlich.

In einem Byte-Literal bedeutet *Zeichen* ein *Byte* mit dem gegebenen Wert. In einem String-Literal bedeutet es ein Unicode-Zeichen mit dem gegebenen Wert.

2.5.4.5. Benanntes Unicode-Zeichen¶

Die Sequenz \N{name} bezeichnet ein Unicode-Zeichen mit dem gegebenen *Namen*.

>>> '\N{LATIN CAPITAL LETTER P}'
'P'
>>> '\N{SNAKE}'
'🐍'

Diese Sequenz kann nicht in Byte-Literalen vorkommen.

Geändert in Version 3.3: Unterstützung für Namensaliase wurde hinzugefügt.

2.5.4.6. Hexadezimale Unicode-Zeichen¶

Diese Sequenzen \uxxxx und \Uxxxxxxxx bezeichnen das Unicode-Zeichen mit dem gegebenen hexadezimalen (Basis 16) Wert. Genau vier Ziffern sind für \u erforderlich; genau acht Ziffern sind für \U erforderlich. Letzteres kann jedes Unicode-Zeichen kodieren.

>>> '\u1234'
'ሴ'
>>> '\U0001f40d'
'🐍'

Diese Sequenzen können nicht in Byte-Literalen vorkommen.

2.5.4.7. Nicht erkannte Escape-Sequenzen¶

Im Gegensatz zu Standard-C bleiben alle nicht erkannten Escape-Sequenzen unverändert im String, d.h. *der Backslash bleibt im Ergebnis erhalten*.

>>> print('\q')
\q
>>> list('\q')
['\\', 'q']

Beachten Sie, dass für Byte-Literale die nur in String-Literalen erkannten Escape-Sequenzen (\N..., \u..., \U...) in die Kategorie der nicht erkannten Escapes fallen.

Geändert in Version 3.6: Nicht erkannte Escape-Sequenzen erzeugen eine DeprecationWarning.

Geändert in Version 3.12: Nicht erkannte Escape-Sequenzen erzeugen eine SyntaxWarning. In einer zukünftigen Python-Version werden sie einen SyntaxError auslösen.

2.5.5. Byte-Literale¶

*Byte-Literale* werden immer mit 'b' oder 'B' vorangestellt; sie erzeugen eine Instanz des Typs bytes anstelle des Typs str. Sie dürfen nur ASCII-Zeichen enthalten; Bytes mit einem numerischen Wert von 128 oder höher müssen mit Escape-Sequenzen ausgedrückt werden (typischerweise Hexadezimales Zeichen oder Oktales Zeichen).

>>> b'\x89PNG\r\n\x1a\n'
b'\x89PNG\r\n\x1a\n'
>>> list(b'\x89PNG\r\n\x1a\n')
[137, 80, 78, 71, 13, 10, 26, 10]

Ebenso muss ein Null-Byte mit einer Escape-Sequenz ausgedrückt werden (typischerweise \0 oder \x00).

2.5.6. Raw-String-Literale¶

Sowohl String- als auch Byte-Literale können optional mit dem Buchstaben 'r' oder 'R' vorangestellt werden; solche Konstrukte werden als *Raw-String-Literale* bzw. *Raw-Byte-Literale* bezeichnet und behandeln Backslashes als literale Zeichen. Infolgedessen werden in Raw-String-Literalen Escape-Sequenzen nicht speziell behandelt.

>>> r'\d{4}-\d{2}-\d{2}'
'\\d{4}-\\d{2}-\\d{2}'

Selbst in einem Raw-Literal können Anführungszeichen mit einem Backslash escaped werden, aber der Backslash bleibt im Ergebnis erhalten; zum Beispiel ist r"\"" ein gültiges String-Literal, das aus zwei Zeichen besteht: einem Backslash und einem doppelten Anführungszeichen; r"\" ist kein gültiges String-Literal (selbst ein Raw-String kann nicht mit einer ungeraden Anzahl von Backslashes enden). Insbesondere kann *ein Raw-Literal nicht mit einem einzelnen Backslash enden* (da der Backslash das folgende Anführungszeichen maskieren würde). Beachten Sie auch, dass ein einzelner Backslash gefolgt von einem Zeilenumbruch als diese beiden Zeichen interpretiert wird und *nicht* als Zeilenfortsetzung.

2.5.7. f-Strings¶

Hinzugefügt in Version 3.6.

Ein *formatiertes String-Literal* oder *f-String* ist ein String-Literal, das mit 'f' oder 'F' vorangestellt ist. Diese Strings können Ersetzungsfelder enthalten, die durch geschweifte Klammern {} abgegrenzte Ausdrücke sind. Während andere String-Literale immer einen konstanten Wert haben, sind formatierte Strings tatsächlich Ausdrücke, die zur Laufzeit ausgewertet werden.

Escape-Sequenzen werden wie in normalen String-Literalen dekodiert (außer wenn ein Literal auch als Raw-String markiert ist). Nach der Dekodierung lautet die Grammatik für den Inhalt des Strings:

f_string:          (literal_char | "{{" | "}}" | replacement_field)*
replacement_field: "{" f_expression ["="] ["!" conversion] [":" format_spec] "}"
f_expression:      (conditional_expression | "*" or_expr)
                     ("," conditional_expression | "," "*" or_expr)* [","]
                   | yield_expression
conversion:        "s" | "r" | "a"
format_spec:       (literal_char | replacement_field)*
literal_char:      <any code point except "{", "}" or NULL>

Die Teile des Strings außerhalb von geschweiften Klammern werden wörtlich behandelt, mit der Ausnahme, dass doppelte geschweifte Klammern '{{' oder '}}' durch die entsprechende einzelne geschweifte Klammer ersetzt werden. Eine einzelne öffnende geschweifte Klammer '{' kennzeichnet ein Ersetzungsfeld, das mit einem Python-Ausdruck beginnt. Um sowohl den Expressionstext als auch seinen ausgewerteten Wert anzuzeigen (nützlich beim Debugging), kann nach dem Ausdruck ein Gleichheitszeichen '=' hinzugefügt werden. Ein Konversionsfeld, eingeleitet durch ein Ausrufezeichen '!', kann folgen. Ein Format-Spezifizierer kann ebenfalls angehängt werden, eingeleitet durch einen Doppelpunkt ':'. Ein Ersetzungsfeld endet mit einer schließenden geschweiften Klammer '}'.

Ausdrücke in formatierten String-Literalen werden wie normale Python-Ausdrücke behandelt, die in Klammern eingeschlossen sind, mit einigen Ausnahmen. Ein leerer Ausdruck ist nicht erlaubt, und sowohl lambda- als auch Zuweisungsausdrücke := müssen in explizite Klammern eingeschlossen sein. Jeder Ausdruck wird im Kontext, in dem das formatierte String-Literal erscheint, von links nach rechts ausgewertet. Ersetzungsdrücke können Zeilenumbrüche in ein- und dreifach Anführungszeichen-f-Strings enthalten und können Kommentare enthalten. Alles, was nach einem # innerhalb eines Ersetzungsfeldes kommt, ist ein Kommentar (auch schließende Klammern und Anführungszeichen). In diesem Fall müssen Ersetzungsfelder auf einer anderen Zeile geschlossen werden.

>>> f"abc{a # This is a comment }"
... + 3}"
'abc5'

Geändert in Version 3.7: Vor Python 3.7 waren await-Ausdrücke und Comprehensions mit einer async for-Klausel aufgrund eines Implementierungsproblems in den Ausdrücken von formatierten String-Literalen illegal.

Geändert in Version 3.12: Vor Python 3.12 waren Kommentare in f-String-Ersetzungsfeldern nicht erlaubt.

Wenn das Gleichheitszeichen '=' bereitgestellt wird, enthält die Ausgabe den Expressionstext, das '=' und den ausgewerteten Wert. Leerzeichen nach der öffnenden Klammer '{', innerhalb des Ausdrucks und nach dem '=' werden alle in der Ausgabe beibehalten. Standardmäßig bewirkt das '=', dass der repr() des Ausdrucks bereitgestellt wird, es sei denn, es gibt einen Format-Spezifizierer. Wenn ein Format angegeben ist, wird standardmäßig der str() des Ausdrucks verwendet, es sei denn, eine Konversion '!r' ist deklariert.

Hinzugefügt in Version 3.8: Das Gleichheitszeichen '='.

Wenn eine Konversion angegeben ist, wird das Ergebnis der Auswertung des Ausdrucks vor der Formatierung konvertiert. Konversion '!s' ruft str() auf dem Ergebnis auf, '!r' ruft repr() auf, und '!a' ruft ascii() auf.

Das Ergebnis wird dann unter Verwendung des format()-Protokolls formatiert. Der Format-Spezifizierer wird an die Methode __format__() des Ausdrucks oder des Konversionsergebnisses übergeben. Ein leerer String wird übergeben, wenn der Format-Spezifizierer weggelassen wird. Das formatierte Ergebnis wird dann in den Gesamtwert des gesamten Strings aufgenommen.

Format-Spezifizierer auf oberster Ebene können verschachtelte Ersetzungsfelder enthalten. Diese verschachtelten Felder können ihre eigenen Konversionsfelder und Format-Spezifizierer enthalten, dürfen aber keine tiefer verschachtelten Ersetzungsfelder enthalten. Die Mini-Sprache für Format-Spezifizierer ist dieselbe wie die, die von der Methode str.format() verwendet wird.

Formatierte String-Literale können verkettet werden, aber Ersetzungsfelder können nicht über Literale hinweg aufgeteilt werden.

Einige Beispiele für formatierte String-Literale

>>> name = "Fred"
>>> f"He said his name is {name!r}."
"He said his name is 'Fred'."
>>> f"He said his name is {repr(name)}."  # repr() is equivalent to !r
"He said his name is 'Fred'."
>>> width = 10
>>> precision = 4
>>> value = decimal.Decimal("12.34567")
>>> f"result: {value:{width}.{precision}}"  # nested fields
'result:      12.35'
>>> today = datetime(year=2017, month=1, day=27)
>>> f"{today:%B %d, %Y}"  # using date format specifier
'January 27, 2017'
>>> f"{today=:%B %d, %Y}" # using date format specifier and debugging
'today=January 27, 2017'
>>> number = 1024
>>> f"{number:#0x}"  # using integer format specifier
'0x400'
>>> foo = "bar"
>>> f"{ foo = }" # preserves whitespace
" foo = 'bar'"
>>> line = "The mill's closed"
>>> f"{line = }"
'line = "The mill\'s closed"'
>>> f"{line = :20}"
"line = The mill's closed   "
>>> f"{line = !r:20}"
'line = "The mill\'s closed" '

Die Wiederverwendung des äußeren f-String-Quoting-Typs innerhalb eines Ersetzungsfeldes ist erlaubt.

>>> a = dict(x=2)
>>> f"abc {a["x"]} def"
'abc 2 def'

Geändert in Version 3.12: Vor Python 3.12 war die Wiederverwendung desselben Quoting-Typs des äußeren f-Strings innerhalb eines Ersetzungsfeldes nicht möglich.

Backslashes sind auch in Ersetzungsfeldern erlaubt und werden auf die gleiche Weise wie in jedem anderen Kontext ausgewertet.

>>> a = ["a", "b", "c"]
>>> print(f"List a contains:\n{"\n".join(a)}")
List a contains:
a
b
c

Geändert in Version 3.12: Vor Python 3.12 waren Backslashes in f-String-Ersetzungsfeldern nicht erlaubt.

Formatierte String-Literale können nicht als Docstrings verwendet werden, auch wenn sie keine Ausdrücke enthalten.

>>> def foo():
...     f"Not a docstring"
...
>>> foo.__doc__ is None
True

Siehe auch PEP 498 für den Vorschlag, der formatierte String-Literale hinzugefügt hat, und str.format(), das einen verwandten Format-String-Mechanismus verwendet.

2.5.8. t-Strings¶

Hinzugefügt in Version 3.14.

Ein *Template-String-Literal* oder *t-String* ist ein String-Literal, das mit 't' oder 'T' vorangestellt ist. Diese Strings folgen der gleichen Syntax und den gleichen Auswertungsregeln wie formatierte String-Literale, mit den folgenden Unterschieden:

Anstatt zu einem str-Objekt ausgewertet zu werden, werden Template-String-Literale zu einem string.templatelib.Template-Objekt ausgewertet.
Das format()-Protokoll wird nicht verwendet. Stattdessen werden der Format-Spezifizierer und Konversionen (falls vorhanden) an ein neues Interpolation-Objekt übergeben, das für jeden ausgewerteten Ausdruck erstellt wird. Es liegt am Code, der das resultierende Template-Objekt verarbeitet, zu entscheiden, wie Format-Spezifizierer und Konversionen behandelt werden.
Format-Spezifizierer, die verschachtelte Ersetzungsfelder enthalten, werden eilig ausgewertet, bevor sie an das Interpolation-Objekt übergeben werden. Zum Beispiel wird eine Interpolation der Form {amount:.{precision}f} den inneren Ausdruck {precision} auswerten, um den Wert des Attributs format_spec zu bestimmen. Wenn precision 2 wäre, wäre der resultierende Format-Spezifizierer '.2f'.
Wenn das Gleichheitszeichen '=' in einem Interpolationsausdruck bereitgestellt wird, wird der Text des Ausdrucks an den String angehängt, der dem entsprechenden Interpolationsausdruck vorausgeht. Dies schließt das Gleichheitszeichen und alle umliegenden Leerzeichen ein. Die Interpolation-Instanz für den Ausdruck wird wie üblich erstellt, außer dass conversion standardmäßig auf 'r' (repr()) gesetzt wird. Wenn eine explizite Konversion oder ein Format-Spezifizierer angegeben ist, wird das Standardverhalten überschrieben.

2.6. Numerische Literale¶

NUMBER-Token repräsentieren numerische Literale, von denen es drei Arten gibt: Ganzzahlen, Gleitkommazahlen und imaginäre Zahlen.

NUMBER: integer | floatnumber | imagnumber

Der numerische Wert eines numerischen Literals ist derselbe, als ob er als String an den Konstruktor der Klasse int, float oder complex übergeben worden wäre. Beachten Sie, dass nicht alle gültigen Eingaben für diese Konstruktoren auch gültige Literale sind.

Numerische Literale enthalten kein Vorzeichen; ein Ausdruck wie -1 ist tatsächlich ein Ausdruck, der aus dem unären Operator '-' und dem Literal 1 besteht.

2.6.1. Ganzzahl-Literale¶

Ganzzahl-Literale bezeichnen ganze Zahlen. Zum Beispiel:

7
3
2147483647

Die Länge von Ganzzahl-Literalen ist unbegrenzt, abgesehen davon, was im verfügbaren Speicher gespeichert werden kann.

7922816251426433759354395033679228162514264337593543950336

Unterstriche können verwendet werden, um Ziffern zur besseren Lesbarkeit zu gruppieren, und werden bei der Ermittlung des numerischen Werts des Literals ignoriert. Zum Beispiel sind die folgenden Literale äquivalent:

100_000_000_000
100000000000
1_00_00_00_00_000

Unterstriche können nur zwischen Ziffern auftreten. Zum Beispiel sind _123, 321_ und 123__321 *keine* gültigen Literale.

Ganzzahlen können in binärer (Basis 2), oktaler (Basis 8) oder hexadezimaler (Basis 16) Form mit den Präfixen 0b, 0o bzw. 0x angegeben werden. Hexadezimale Ziffern 10 bis 15 werden durch die Buchstaben A-F dargestellt, case-insensitiv. Zum Beispiel:

0b100110111
0b_1110_0101
0o177
0o377
0xdeadbeef
0xDead_Beef

Ein Unterstrich kann auf den Basis-Spezifizierer folgen. Zum Beispiel ist 0x_1f ein gültiges Literal, aber 0_x1f und 0x__1f sind es nicht.

Führende Nullen in einer nicht-null dezimalen Zahl sind nicht erlaubt. Zum Beispiel ist 0123 kein gültiges Literal. Dies dient zur Unterscheidung von C-Style-Oktalzahlen, die Python vor Version 3.0 verwendete.

Formal sind Ganzzahl-Literale durch die folgenden lexikalischen Definitionen beschrieben:

integer:      decinteger | bininteger | octinteger | hexinteger | zerointeger
decinteger:   nonzerodigit (["_"] digit)*
bininteger:   "0" ("b" | "B") (["_"] bindigit)+
octinteger:   "0" ("o" | "O") (["_"] octdigit)+
hexinteger:   "0" ("x" | "X") (["_"] hexdigit)+
zerointeger:  "0"+ (["_"] "0")*
nonzerodigit: "1"..."9"
digit:        "0"..."9"
bindigit:     "0" | "1"
octdigit:     "0"..."7"
hexdigit:     digit | "a"..."f" | "A"..."F"

Geändert in Version 3.6: Unterstriche sind jetzt zur Gruppierung in Literalen erlaubt.

2.6.2. Gleitkomma-Literale¶

Gleitkomma-Literale (float), wie 3.14 oder 1.5, bezeichnen *Annäherungen von reellen Zahlen*.

Sie bestehen aus einem *Ganzzahlteil* und einem *Bruchteil*, die jeweils aus Dezimalziffern bestehen. Die Teile sind durch einen Dezimalpunkt, ., getrennt.

2.71828
4.0

Im Gegensatz zu Ganzzahl-Literalen sind führende Nullen erlaubt. Zum Beispiel ist 077.010 legal und bezeichnet die gleiche Zahl wie 77.01.

Wie in Ganzzahl-Literalen können einzelne Unterstriche zwischen Ziffern auftreten, um die Lesbarkeit zu verbessern.

96_485.332_123
3.14_15_93

Einer dieser Teile, aber nicht beide, kann leer sein. Zum Beispiel:

10.  # (equivalent to 10.0)
.001  # (equivalent to 0.001)

Optional können die Ganzzahl und der Bruch von einem *Exponent* gefolgt werden: der Buchstabe e oder E, gefolgt von einem optionalen Vorzeichen, + oder -, und einer Zahl im gleichen Format wie die Ganzzahl- und Bruchteile. Das e oder E steht für „mal zehn hoch“.

0e3  # (represents 1.0×10³, or 1000.0)
166e-5  # (represents 1.166×10⁻⁵, or 0.00001166)
02214076e+23  # (represents 6.02214076×10²³, or 602214076000000000000000.)

Bei Gleitkommazahlen mit nur ganzzahligen und exponentiellen Teilen kann der Dezimalpunkt weggelassen werden.

1e3  # (equivalent to 1.e3 and 1.0e3)
0e0  # (equivalent to 0.)

Formal sind Gleitkomma-Literale durch die folgenden lexikalischen Definitionen beschrieben:

floatnumber:
   | digitpart "." [digitpart] [exponent]
   | "." digitpart [exponent]
   | digitpart exponent
digitpart: digit (["_"] digit)*
exponent:  ("e" | "E") ["+" | "-"] digitpart

Geändert in Version 3.6: Unterstriche sind jetzt zur Gruppierung in Literalen erlaubt.

2.6.3. Imaginäre Literale¶

Python verfügt über *komplexe Zahlen*-Objekte, aber keine komplexen Literale. Stattdessen bezeichnen *imaginäre Literale* komplexe Zahlen mit einem reellen Teil von Null.

Zum Beispiel wird in der Mathematik die komplexe Zahl 3+4.2i als reelle Zahl 3 plus die imaginäre Zahl 4.2i geschrieben. Python verwendet eine ähnliche Syntax, wobei die imaginäre Einheit als j anstelle von i geschrieben wird.

3+4.2j

Dies ist ein Ausdruck, der aus dem Ganzzahl-Literal 3, dem Operator '+' und dem imaginären Literal 4.2j besteht. Da dies drei separate Token sind, sind Leerzeichen zwischen ihnen erlaubt.

3 + 4.2j

Innerhalb jedes Tokens sind keine Leerzeichen erlaubt. Insbesondere darf das j-Suffix nicht vom vorhergehenden Zahlenwert getrennt werden.

Die Zahl vor dem j hat die gleiche Syntax wie ein Gleitkomma-Literal. Daher sind die folgenden gültige imaginäre Literale:

2j
14j
j
.001j
1e100j
14e-10j
14_15_93j

Im Gegensatz zu einem Gleitkomma-Literal kann der Dezimalpunkt weggelassen werden, wenn die imaginäre Zahl nur einen Ganzzahlteil hat. Die Zahl wird immer noch als Gleitkommazahl und nicht als Ganzzahl ausgewertet.

10j
0j
1000000000000000000000000j   # equivalent to 1e+24j

Das j-Suffix ist nicht case-sensitiv. Das bedeutet, Sie können auch J verwenden.

3.14J   # equivalent to 3.14j

Formal sind imaginäre Literale durch die folgende lexikalische Definition beschrieben:

imagnumber: (floatnumber | digitpart) ("j" | "J")

2.7. Operatoren und Trennzeichen¶

Die folgende Grammatik definiert *Operator*- und *Trennzeichen*-Token, d. h. den generischen Token-Typ OP. Eine Liste dieser Token und ihrer Namen ist auch in der Dokumentation des token-Moduls verfügbar.

OP:
   | assignment_operator
   | bitwise_operator
   | comparison_operator
   | enclosing_delimiter
   | other_delimiter
   | arithmetic_operator
   | "..."
   | other_op

assignment_operator:   "+=" | "-=" | "*=" | "**=" | "/="  | "//=" | "%=" |
                       "&=" | "|=" | "^=" | "<<=" | ">>=" | "@="  | ":="
bitwise_operator:      "&"  | "|"  | "^"  | "~"   | "<<"  | ">>"
comparison_operator:   "<=" | ">=" | "<"  | ">"   | "=="  | "!="
enclosing_delimiter:   "("  | ")"  | "["  | "]"   | "{"   | "}"
other_delimiter:       ","  | ":"  | "!"  | ";"   | "="   | "->"
arithmetic_operator:   "+"  | "-"  | "**" | "*"   | "//"  | "/"   | "%"
other_op:              "."  | "@"

Hinweis

Im Allgemeinen werden *Operatoren* verwendet, um Ausdrücke zu kombinieren, während *Trennzeichen* anderen Zwecken dienen. Es gibt jedoch keine klare, formale Unterscheidung zwischen den beiden Kategorien.

Einige Token können je nach Verwendung sowohl als Operatoren als auch als Trennzeichen dienen. Zum Beispiel ist * sowohl der Multiplikationsoperator als auch ein Trennzeichen, das zum Entpacken von Sequenzen verwendet wird, und @ ist sowohl die Matrixmultiplikation als auch ein Trennzeichen, das Dekoratoren einleitet.

Bei einigen Tokens ist die Unterscheidung unklar. Zum Beispiel betrachten einige Leute ., ( und ) als Trennzeichen, während andere den getattr() Operator und den Funktionsaufrufoperator(en) sehen.

Einige von Pythons Operatoren, wie and, or und not in, verwenden Schlüsselwort-Tokens anstelle von „Symbolen“ (Operator-Tokens).

Eine Sequenz von drei aufeinanderfolgenden Punkten (...) hat eine spezielle Bedeutung als Ellipsis-Literal.