1. Einführung
*************

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

Während ich versuche, so präzise wie möglich zu sein, habe ich mich
dafür entschieden, für alles außer der Syntax und der lexikalischen
Analyse einfaches Englisch statt formaler Spezifikationen zu
verwenden. Dies sollte das Dokument für den durchschnittlichen Leser
verständlicher machen, lässt jedoch Raum für Mehrdeutigkeiten. Wenn
Sie also vom Mars kämen und versuchten, Python allein anhand dieses
Dokuments neu zu implementieren, müssten Sie unter Umständen Dinge
erraten und würden am Ende wahrscheinlich eine ganz andere Sprache
implementieren. Wenn Sie hingegen 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
formalere Definition der Sprache wünschen, könnten Sie vielleicht Ihre
Zeit opfern --- oder eine Klonmaschine erfinden :-).

Es ist gefährlich, einem Sprachreferenzdokument zu viele
Implementierungsdetails hinzuzufügen --- die Implementierung kann sich
ändern, und andere Implementierungen derselben Sprache können anders
funktionieren. Andererseits ist CPython die am weitesten verbreitete
Python-Implementierung (obwohl alternative Implementierungen weiter an
Unterstützung gewinnen), und ihre speziellen Eigenheiten sind es
manchmal wert, erwähnt zu werden, insbesondere dort, wo die
Implementierung zusätzliche Einschränkungen mit sich bringt. Daher
finden sich im gesamten Text verstreut kurze
„Implementierungshinweise“.

Jede Python-Implementierung bringt eine Reihe von eingebauten und
Standard-Modulen mit. Diese sind in The Python standard library
dokumentiert. Einige wenige eingebaute Module werden erwähnt, wenn sie
in wesentlicher Weise mit der Sprachdefinition interagieren.


1.1. Alternative Implementierungen
==================================

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

Zu den bekannten Implementierungen gehören:

CPython
   Dies ist die ursprüngliche und am meisten gepflegte Implementierung
   von Python, geschrieben in C. Neue Sprachmerkmale erscheinen hier
   in der Regel zuerst.

Jython
   Python implementiert in Java. 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 häufig verwendet, um
   Tests für Java-Bibliotheken zu schreiben. Weitere Informationen
   sind auf der Jython-Website zu finden.

Python for .NET
   Diese Implementierung verwendet tatsächlich die CPython-
   Implementierung, ist jedoch eine verwaltete .NET-Anwendung und
   stellt .NET-Bibliotheken zur Verfügung. Sie wurde von Brian Lloyd
   entwickelt. Weitere Informationen finden Sie auf der Python for
   .NET-Startseite.

IronPython
   Ein alternatives 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, entwickelt.
   Weitere Informationen finden Sie auf der IronPython-Website.

PyPy
   Eine vollständig in Python geschriebene Implementierung von Python.
   Sie unterstützt verschiedene fortgeschrittene Funktionen, die in
   anderen Implementierungen nicht zu finden sind, wie etwa Stackless-
   Unterstützung und einen Just-in-Time-Compiler. Eines der Ziele des
   Projekts ist es, zum Experimentieren mit der Sprache selbst
   anzuregen, indem es einfacher gemacht wird, den Interpreter
   anzupassen (da er in Python geschrieben ist). Weitere Informationen
   sind auf der Startseite des PyPy-Projekts verfügbar.

Jede dieser Implementierungen weicht in irgendeiner Weise von der in
diesem Handbuch dokumentierten Sprache ab oder führt spezifische
Informationen über das hinaus ein, was in der Standard-Python-
Dokumentation behandelt wird. Bitte ziehen Sie die
implementierungsspezifische Dokumentation zurate, um zu erfahren, was
Sie sonst noch über die von Ihnen verwendete Implementierung wissen
müssen.


1.2. Notation
=============

Die Beschreibungen der lexikalischen Analyse und Syntax verwenden eine
Grammatik-Notation, 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" ist, gefolgt von einer Sequenz aus null oder mehr "letter"n,
"digit"s und Unterstrichen. Ein "letter" wiederum ist ein beliebiges
Einzelzeichen von "'a'" bis "'z'" sowie "A" bis "Z", ein "digit" ist
ein Einzelzeichen 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, handelt
  es sich um einen Link zur Definition der Regel.

  * "TOKEN": Ein in Großbuchstaben geschriebener Name verweist auf ein
    *Token*. Für die Zwecke von Grammatikdefinitionen sind Tokens
    dasselbe wie Regeln.

* ""text"", "'text'": Text in einfachen oder doppelten
  Anführungszeichen muss buchstäblich (ohne die Anführungszeichen)
  übereinstimmen. Die Art der Anführungszeichen wird entsprechend der
  Bedeutung von "text" gewählt:

  * "'if'": Ein Name in einfachen Anführungszeichen kennzeichnet ein
    Schlüsselwort.

  * ""case"": Ein Name in doppelten Anführungszeichen kennzeichnet ein
    Soft-Schlüsselwort.

  * "'@'": Ein Symbol, das kein Buchstabe ist, in einfachen
    Anführungszeichen kennzeichnet ein "OP"-Token, das heißt ein
    Trennzeichen oder einen Operator.

* "e1 e2": Elemente, die nur durch Leerzeichen getrennt sind,
  bezeichnen eine Sequenz. Hier muss "e1" von "e2" gefolgt werden.

* "e1 | e2": Ein senkrechter Strich wird verwendet, um Alternativen zu
  trennen. Er bezeichnet PEGs „geordnete Auswahl“ (ordered choice):
  Wenn "e1" passt, wird "e2" nicht berücksichtigt. In traditionellen
  PEG-Grammatiken wird dies als Schrägstrich, "/", anstelle eines
  senkrechten Strichs 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 ein oder mehr Wiederholungen.

* "[e]": Ein in eckige Klammern eingeschlossener Ausdruck bedeutet
  null oder ein Vorkommen. Mit anderen Worten: Der eingeschlossene
  Ausdruck ist optional.

* "e?": Ein Fragezeichen hat exakt dieselbe Bedeutung wie eckige
  Klammern: Das vorhergehende Element ist optional.

* "(e)": Runde Klammern werden zur Gruppierung verwendet.

Die folgende Notation wird nur in lexikalischen Definitionen
verwendet.

* ""a"..."z"": Zwei Literalzeichen, die durch drei Punkte getrennt
  sind, bedeuten die Auswahl eines beliebigen Einzelzeichens im
  angegebenen (inklusiven) Bereich von ASCII-Zeichen.

* "<...>": Ein Ausdruck in spitzen Klammern liefert eine informelle
  Beschreibung des passenden Symbols (zum Beispiel "<any ASCII
  character except "\">") oder eine Abkürzung, die im umgebenden Text
  definiert ist (zum Beispiel "<Lu>").

Einige Definitionen verwenden auch *Lookaheads*, die angeben, dass ein
Element an einer bestimmten Position passen muss (oder nicht passen
darf), jedoch ohne eine Eingabe zu konsumieren:

* "&e": ein positiver Lookahead (das heißt, "e" muss zwingend passen)

* "!e": ein negativer Lookahead (das heißt, "e" darf zwingend *nicht*
  passen)

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

Whitespace dient ausschließlich dazu, Tokens voneinander zu trennen.

Regeln stehen normalerweise in einer einzelnen Zeile, zu lange Regeln
können jedoch umgebrochen werden:

   literal: stringliteral | bytesliteral
            | integer | floatnumber | imagnumber

Alternativ können Regeln so formatiert werden, dass die erste Zeile
mit dem 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 einen Unterschied zwischen *lexikalischer* und *syntaktischer*
Analyse: Der *Lexikalische Analysierer* arbeitet auf den einzelnen
Zeichen der Eingabequelle, während der *Parser* (syntaktischer
Analysierer) auf dem Datenstrom von *Tokens* arbeitet, die von der
lexikalischen Analyse erzeugt wurden. In manchen Fällen ist die genaue
Grenze zwischen den beiden Phasen jedoch ein CPython-
Implementierungsdetail.

Der praktische Unterschied zwischen beiden besteht darin, dass in
*lexikalischen* Definitionen sämtlicher Whitespace signifikant ist.
Der lexikalische Analysierer verwirft allen Whitespace, der nicht in
Tokens wie "token.INDENT" oder "NEWLINE" umgewandelt wird.
*Syntaktische* Definitionen verwenden dann diese Tokens anstelle von
Quelltext-Zeichen.

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