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.
