1. Einführung

Dieses Referenzhandbuch beschreibt die Python-Programmiersprache. Es ist nicht als Tutorial gedacht.

Obwohl ich versuche, so präzise wie möglich zu sein, habe ich mich entschieden, Englisch anstelle formaler Spezifikationen für alles außer Syntax und lexikalischer Analyse zu verwenden. Dies sollte das Dokument für den durchschnittlichen Leser verständlicher machen, lässt jedoch Raum für Mehrdeutigkeiten. Folglich, wenn Sie von Mars kämen und versuchten, Python nur anhand dieses Dokuments neu zu implementieren, müssten Sie möglicherweise raten, und tatsächlich würden Sie wahrscheinlich eine ganz andere Sprache implementieren. Andererseits, wenn Sie Python verwenden und sich fragen, wie die genauen Regeln für einen bestimmten Bereich der Sprache lauten, sollten Sie diese hier definitiv finden können. Wenn Sie eine formellere Definition der Sprache sehen möchten, könnten Sie vielleicht Ihre Zeit anbieten – oder eine Klonmaschine erfinden :-).

Es ist gefährlich, zu viele Implementierungsdetails in ein Sprachreferenzdokument aufzunehmen – die Implementierung kann sich ändern, und andere Implementierungen derselben Sprache können anders funktionieren. Andererseits ist CPython die bei weitem am weitesten verbreitete Python-Implementierung (obwohl alternative Implementierungen weiterhin Unterstützung gewinnen), und ihre spezifischen Eigenheiten sind manchmal erwähnenswert, insbesondere wenn die Implementierung zusätzliche Einschränkungen auferlegt. Daher finden Sie im Text verstreut kurze „Implementierungsnotizen“.

Jede Python-Implementierung wird mit einer Reihe von integrierten und Standardmodulen geliefert. Diese sind in Die Python-Standardbibliothek dokumentiert. Einige integrierte Module werden erwähnt, wenn sie auf signifikante Weise mit der Sprachdefinition interagieren.

1.1. Alternative Implementierungen

Obwohl es eine Python-Implementierung gibt, die bei weitem die beliebteste ist, gibt es einige alternative Implementierungen, die für unterschiedliche Zielgruppen von besonderem Interesse sind.

Bekannte Implementierungen umfassen

CPython

Dies ist die ursprüngliche und am besten gewartete Implementierung von Python, geschrieben in C. Neue Sprachfunktionen erscheinen hier in der Regel zuerst.

Jython

Python in Java implementiert. Diese Implementierung kann als Skriptsprache für Java-Anwendungen verwendet werden oder zur Erstellung von Anwendungen unter Verwendung der Java-Klassenbibliotheken dienen. Sie wird auch oft zur Erstellung von Tests für Java-Bibliotheken verwendet. Weitere Informationen finden Sie auf der Jython-Website.

Python für .NET

Diese Implementierung verwendet tatsächlich die CPython-Implementierung, ist jedoch eine verwaltete .NET-Anwendung und macht .NET-Bibliotheken verfügbar. Sie wurde von Brian Lloyd erstellt. Weitere Informationen finden Sie auf der Python for .NET-Homepage.

IronPython

Eine alternative Python für .NET. Im Gegensatz zu Python.NET ist dies eine vollständige Python-Implementierung, die IL generiert und Python-Code direkt in .NET-Assemblies kompiliert. Sie wurde von Jim Hugunin, dem ursprünglichen Schöpfer von Jython, erstellt. Weitere Informationen finden Sie auf der IronPython-Website.

PyPy

Eine Implementierung von Python, die vollständig in Python geschrieben ist. Sie unterstützt mehrere erweiterte Funktionen, die in anderen Implementierungen nicht vorhanden sind, wie z. B. Stackless-Unterstützung und einen Just-in-Time-Compiler. Eines der Ziele des Projekts ist die Förderung des Experimentierens mit der Sprache selbst, indem die Modifizierung des Interpreters (da er in Python geschrieben ist) erleichtert wird. Zusätzliche Informationen sind auf der Homepage des PyPy-Projekts verfügbar.

Jede dieser Implementierungen unterscheidet sich in gewisser Weise von der in diesem Handbuch beschriebenen Sprache oder führt spezifische Informationen ein, die über das hinausgehen, was in der Standard-Python-Dokumentation behandelt wird. Bitte beziehen Sie sich auf die implementierungsspezifische Dokumentation, um festzustellen, was Sie über die spezifische Implementierung, die Sie verwenden, noch wissen müssen.

1.2. Notation

Die Beschreibungen der lexikalischen Analyse und Syntax verwenden eine Grammatiknotation, die eine Mischung aus EBNF und PEG ist. Zum Beispiel

name:   letter (letter | digit | "_")*
letter: "a"..."z" | "A"..."Z"
digit:  "0"..."9"

In diesem Beispiel besagt die erste Zeile, dass ein name ein letter gefolgt von einer Folge von null oder mehr lettern, digits und Unterstrichen ist. Ein letter ist wiederum ein beliebiges einzelnes Zeichen von 'a' bis 'z' und A bis Z; ein digit ist ein einzelnes Zeichen von 0 bis 9.

Jede Regel beginnt mit einem Namen (der die zu definierende Regel identifiziert), gefolgt von einem Doppelpunkt, :. Die Definition rechts vom Doppelpunkt verwendet die folgenden Syntaxelemente

• name: Ein Name verweist auf eine andere Regel. Wo möglich, ist er ein Link zur Definition der Regel.

  • TOKEN: Ein Großbuchstabenname verweist auf ein Token. Für Grammatikdefinitionen sind Tokens dieselben wie Regeln.

• "text", 'text': Text in einfachen oder doppelten Anführungszeichen muss wörtlich übereinstimmen (ohne die Anführungszeichen). Die Art des Anführungszeichens wird entsprechend der Bedeutung von text gewählt.

  • 'if': Ein Name in einfachen Anführungszeichen bezeichnet ein Schlüsselwort.

  • "case": Ein Name in doppelten Anführungszeichen bezeichnet ein Soft-Keyword.

  • '@': Ein nicht-Buchstabensymbol in einfachen Anführungszeichen bezeichnet ein OP-Token, d. h. einen Trennzeichen oder einen Operator.

• e1 e2: Nur durch Leerzeichen getrennte Elemente bezeichnen eine Sequenz. Hier muss e1 von e2 gefolgt werden.

• e1 | e2: Ein senkrechter Strich wird zur Trennung von Alternativen verwendet. Er bezeichnet die „geordnete Wahl“ von PEG: Wenn e1 übereinstimmt, wird e2 nicht berücksichtigt. In traditionellen PEG-Grammatiken wird dies anstelle eines senkrechten Strichs als Schrägstrich / geschrieben. Siehe PEP 617 für weitere Hintergründe und Details.

• e*: Ein Stern bedeutet null oder mehr Wiederholungen des vorhergehenden Elements.

• e+: Ebenso bedeutet ein Plus eins oder mehr Wiederholungen.

• [e]: Ein in eckige Klammern eingeschlossener Ausdruck bedeutet null oder eine einzelne Vorkommen. Mit anderen Worten, der eingeschlossene Ausdruck ist optional.

• e?: Ein Fragezeichen hat genau dieselbe Bedeutung wie eckige Klammern: das vorhergehende Element ist optional.

• (e): Klammern werden zur Gruppierung verwendet.

Die folgende Notation wird nur in lexikalischen Definitionen verwendet.

• "a"..."z": Zwei Literalzeichen, getrennt durch drei Punkte, bedeuten die Wahl eines beliebigen einzelnen Zeichens im angegebenen (einschließlich) Bereich von ASCII-Zeichen.

• <...>: Ein Ausdruck zwischen spitzen Klammern gibt eine informelle Beschreibung des übereinstimmenden Symbols (z. B. <jedes ASCII-Zeichen außer "\">) oder eine Abkürzung, die im umgebenden Text definiert ist (z. B. <Lu>).

Einige Definitionen verwenden auch Lookaheads, die angeben, dass ein Element an einer bestimmten Position übereinstimmen muss (oder nicht übereinstimmen darf), ohne jedoch Eingaben zu verbrauchen.

• &e: Ein positiver Lookahead (d. h. e muss übereinstimmen)

• !e: Ein negativer Lookahead (d. h. e darf nicht übereinstimmen)

Die unären Operatoren (*, +, ?) binden so fest wie möglich; der senkrechte Strich (|) bindet am lockersten.

Leerzeichen sind nur zur Trennung von Tokens bedeutsam.

Regeln sind normalerweise auf einer einzigen Zeile enthalten, aber zu lange Regeln können umgebrochen werden.

literal: stringliteral | bytesliteral
         | integer | floatnumber | imagnumber

Alternativ können Regeln so formatiert werden, dass die erste Zeile am Doppelpunkt endet und jede Alternative mit einem senkrechten Strich in einer neuen Zeile beginnt. Zum Beispiel

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

Dies bedeutet nicht, dass es eine leere erste Alternative gibt.

1.2.1. Lexikalische und syntaktische Definitionen

Es gibt einige Unterschiede zwischen lexikalischer und syntaktischer Analyse: der Lexikalische Analysator arbeitet mit den einzelnen Zeichen des Quelltextes, während der Parser (syntaktischer Analysator) auf dem Strom von Tokens arbeitet, die von der lexikalischen Analyse erzeugt werden. In einigen Fällen ist die genaue Grenze zwischen den beiden Phasen jedoch ein Implementierungsdetail von CPython.

Der praktische Unterschied zwischen den beiden besteht darin, dass in lexikalischen Definitionen alle Leerzeichen bedeutsam sind. Der lexikalische Analysator verwirft alle Leerzeichen, die nicht in Tokens wie token.INDENT oder token.NEWLINE umgewandelt werden. Syntaktische Definitionen verwenden dann diese Tokens anstelle von Quellzeichen.

Diese Dokumentation verwendet dieselbe BNF-Grammatik für beide Arten von Definitionen. Alle Verwendungen von BNF im nächsten Kapitel (Lexikalische Analyse) sind lexikalische Definitionen; Verwendungen in nachfolgenden Kapiteln sind syntaktische Definitionen.