1. Introduction

Ce manuel de référence décrit le langage de programmation Python. Il n'a pas vocation à être un tutoriel.

Nous essayons d'être le plus précis possible et nous utilisons le français (NdT : ou l’anglais pour les parties qui ne sont pas encore traduites) plutôt que des spécifications formelles, sauf pour la syntaxe et l’analyse lexicale. Nous espérons ainsi rendre ce document plus compréhensible pour un grand nombre de lecteurs, même si cela laisse un peu de place à l’ambiguïté. En conséquence, si vous arrivez de Mars et que vous essayez de ré-implémenter Python à partir de cet unique document, vous devrez faire des hypothèses et, finalement, vous aurez certainement implémenté un langage sensiblement différent. D’un autre côté, si vous utilisez Python et que vous vous demandez quelles règles s’appliquent pour telle partie du langage, vous devriez trouver une réponse satisfaisante ici. Si vous souhaitez voir une définition plus formelle du langage, nous acceptons toutes les bonnes volontés (ou bien inventez une machine pour nous cloner ☺).

S’agissant du manuel de référence d’un langage, il est dangereux de rentrer profondément dans les détails d’implémentation ; l’implémentation peut changer et d’autres implémentations du même langage peuvent fonctionner différemment. En même temps, CPython est l’implémentation de Python la plus répandue (bien que d’autres implémentations gagnent en popularité) et certaines de ses bizarreries méritent parfois d’être mentionnées, en particulier lorsque l’implémentation impose des limitations supplémentaires. Par conséquent, vous trouvez de courtes "notes d’implémentation" saupoudrées dans le texte.

Chaque implémentation de Python est livrée avec un certain nombre de modules natifs. Ceux-ci sont documentés dans La bibliothèque standard. Quelques modules natifs sont mentionnés quand ils interagissent significativement avec la définition du langage.

1.1. Autres implémentations

Bien qu’il existe une implémentation Python qui soit de loin la plus populaire, il existe d’autres implémentations qui présentent un intérêt particulier pour différents publics.

Parmi les implémentations les plus connues, nous pouvons citer :

CPython

C’est l’implémentation originelle et la plus entretenue de Python, écrite en C. Elle implémente généralement en premier les nouvelles fonctionnalités du langage.

Jython

Python implemented in Java. This implementation can be used as a scripting language for Java applications, or can be used to create applications using the Java class libraries. It is also often used to create tests for Java libraries. More information can be found at the Jython website.

Python pour .NET

Cette implémentation utilise en fait l’implémentation CPython, mais c’est une application .NET et permet un accès aux bibliothèques .NET. Elle a été créée par Brian Lloyd. Pour plus d’informations, consultez la page d’accueil Python pour .NET (site en anglais).

IronPython

An alternate Python for .NET. Unlike Python.NET, this is a complete Python implementation that generates IL, and compiles Python code directly to .NET assemblies. It was created by Jim Hugunin, the original creator of Jython. For more information, see the IronPython website.

PyPy

An implementation of Python written completely in Python. It supports several advanced features not found in other implementations like stackless support and a Just in Time compiler. One of the goals of the project is to encourage experimentation with the language itself by making it easier to modify the interpreter (since it is written in Python). Additional information is available on the PyPy project's home page.

Chacune de ces implémentations diffère d'une manière ou d'une autre par rapport au langage décrit dans ce manuel, ou comporte des spécificités que la documentation standard de Python ne couvre pas. Reportez-vous à la documentation spécifique à l'implémentation pour déterminer ce que vous devez savoir sur l'implémentation que vous utilisez.

1.2. Notations

The descriptions of lexical analysis and syntax use a grammar notation that is a mixture of EBNF and PEG. For example:

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

In this example, the first line says that a name is a letter followed by a sequence of zero or more letters, digits, and underscores. A letter in turn is any of the single characters 'a' through 'z' and A through Z; a digit is a single character from 0 to 9.

Each rule begins with a name (which identifies the rule that's being defined) followed by a colon, :. The definition to the right of the colon uses the following syntax elements:

  • name: A name refers to another rule. Where possible, it is a link to the rule's definition.

    • TOKEN: An uppercase name refers to a token. For the purposes of grammar definitions, tokens are the same as rules.

  • "text", 'text': Text in single or double quotes must match literally (without the quotes). The type of quote is chosen according to the meaning of text:

    • 'if': A name in single quotes denotes a keyword.

    • "case": A name in double quotes denotes a soft-keyword.

    • '@': A non-letter symbol in single quotes denotes an OP token, that is, a delimiter or operator.

  • e1 e2: Items separated only by whitespace denote a sequence. Here, e1 must be followed by e2.

  • e1 | e2: A vertical bar is used to separate alternatives. It denotes PEG's "ordered choice": if e1 matches, e2 is not considered. In traditional PEG grammars, this is written as a slash, /, rather than a vertical bar. See PEP 617 for more background and details.

  • e*: A star means zero or more repetitions of the preceding item.

  • e+: Likewise, a plus means one or more repetitions.

  • [e]: A phrase enclosed in square brackets means zero or one occurrences. In other words, the enclosed phrase is optional.

  • e?: A question mark has exactly the same meaning as square brackets: the preceding item is optional.

  • (e): Parentheses are used for grouping.

The following notation is only used in lexical definitions.

  • "a"..."z": Two literal characters separated by three dots mean a choice of any single character in the given (inclusive) range of ASCII characters.

  • <...>: A phrase between angular brackets gives an informal description of the matched symbol (for example, <any ASCII character except "\">), or an abbreviation that is defined in nearby text (for example, <Lu>).

Some definitions also use lookaheads, which indicate that an element must (or must not) match at a given position, but without consuming any input:

  • &e: a positive lookahead (that is, e is required to match)

  • !e: a negative lookahead (that is, e is required not to match)

The unary operators (*, +, ?) bind as tightly as possible; the vertical bar (|) binds most loosely.

White space is only meaningful to separate tokens.

Rules are normally contained on a single line, but rules that are too long may be wrapped:

literal: stringliteral | bytesliteral
         | integer | floatnumber | imagnumber

Alternatively, rules may be formatted with the first line ending at the colon, and each alternative beginning with a vertical bar on a new line. For example:

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

This does not mean that there is an empty first alternative.

1.2.1. Lexical and Syntactic definitions

There is some difference between lexical and syntactic analysis: the lexical analyzer operates on the individual characters of the input source, while the parser (syntactic analyzer) operates on the stream of tokens generated by the lexical analysis. However, in some cases the exact boundary between the two phases is a CPython implementation detail.

The practical difference between the two is that in lexical definitions, all whitespace is significant. The lexical analyzer discards all whitespace that is not converted to tokens like token.INDENT or NEWLINE. Syntactic definitions then use these tokens, rather than source characters.

This documentation uses the same BNF grammar for both styles of definitions. All uses of BNF in the next chapter (Analyse lexicale) are lexical definitions; uses in subsequent chapters are syntactic definitions.