# 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 implémenté en Java. Cette implémentation peut être utilisée comme langage de script pour les applications Java ou pour créer des applications utilisant des bibliothèques Java. Elle est également souvent utilisée pour créer des tests de bibliothèques Java. Plus d’informations peuvent être trouvées sur the Jython website (site en anglais).

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

  Un autre Python pour .NET. Contrairement à Python.NET, il s’agit d’une implémentation Python complète qui génère du code intermédiaire (IL) .NET et compile le code Python directement en assemblages .NET. Il a été créé par Jim Hugunin, le programmeur à l’origine de Jython. Pour plus d’informations, voir the IronPython website (site en anglais).

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 `letter`s, `digit`s, 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.