8. Instructions composées
*************************

Les instructions composées contiennent d'autres (groupes d’)
instructions ; elles affectent ou contrôlent l'exécution de ces autres
instructions d'une manière ou d'une autre. En général, une instruction
composée couvre plusieurs lignes bien que, dans sa forme la plus
simple, une instruction composée peut tenir sur une seule ligne.

Les instructions "if", "while" et "for" implémentent les constructions
classiques de contrôle de flux. "try" définit des gestionnaires
d'exception et du code de nettoyage pour un groupe d'instructions,
tandis que l'instruction "with" permet l'exécution de code
d'initialisation et de finalisation autour d'un bloc de code. Les
définitions de fonctions et de classes sont également, au sens
syntaxique, des instructions composées.

Une instruction composée comporte une ou plusieurs « clauses ». Une
clause se compose d'un en-tête et d'une « suite ». Les en-têtes des
clauses d'une instruction composée particulière sont toutes placées au
même niveau d'indentation. Chaque en-tête de clause commence par un
mot-clé spécifique et se termine par le caractère deux-points (":") ;
une suite est un groupe d'instructions contrôlées par une clause ; une
suite se compose, après les deux points de l'en-tête, soit d'une ou
plusieurs instructions simples séparées par des points-virgules si
elles sont sur la même ligne que l'en-tête, soit d'une ou plusieurs
instructions en retrait sur les lignes suivantes. Seule cette dernière
forme d'une suite peut contenir des instructions composées ; ce qui
suit n'est pas licite, principalement parce qu'il ne serait pas clair
de savoir à quelle clause "if" se rapporterait une clause "else"
placée en fin de ligne :

   if test1: if test2: print(x)

Notez également que le point-virgule se lie plus étroitement que le
deux-points dans ce contexte, de sorte que dans l'exemple suivant,
soit tous les appels "print()" sont exécutés, soit aucun ne l'est :

   if x < y < z: print(x); print(y); print(z)

En résumé :

   compound_stmt: if_stmt
                  | while_stmt
                  | for_stmt
                  | try_stmt
                  | with_stmt
                  | match_stmt
                  | funcdef
                  | classdef
                  | async_with_stmt
                  | async_for_stmt
                  | async_funcdef
   suite:         stmt_list NEWLINE | NEWLINE INDENT statement+ DEDENT
   statement:     stmt_list NEWLINE | compound_stmt
   stmt_list:     simple_stmt (";" simple_stmt)* [";"]

Notez que ces instructions se terminent toujours par un lexème
"NEWLINE" suivi éventuellement d'un "DEDENT". Notez également que les
clauses facultatives qui suivent commencent toujours par un mot-clé
qui ne peut pas commencer une instruction. Ainsi, il n'y a pas
d'ambiguïté (le problème du "else" dont on ne sait pas à quel "if" il
est relié est résolu en Python en exigeant que des instructions "if"
imbriquées soient indentées les unes par rapport aux autres).

L'agencement des règles de grammaire dans les sections qui suivent
place chaque clause sur une ligne séparée pour plus de clarté.


8.1. L'instruction "if"
=======================

L'instruction "if" est utilisée pour exécuter des instructions en
fonction d'une condition :

   if_stmt: "if" assignment_expression ":" suite
            ("elif" assignment_expression ":" suite)*
            ["else" ":" suite]

Elle sélectionne exactement une des suites en évaluant les expressions
une par une jusqu'à ce qu'une soit vraie (voir la section Opérations
booléennes pour la définition de vrai et faux) ; ensuite cette suite
est exécutée (et aucune autre partie de l'instruction "if" n'est
exécutée ou évaluée). Si toutes les expressions sont fausses, la suite
de la clause "else", si elle existe, est exécutée.


8.2. L'instruction "while"
==========================

L'instruction "while" est utilisée pour exécuter des instructions de
manière répétée tant qu'une expression est vraie :

   while_stmt: "while" assignment_expression ":" suite
               ["else" ":" suite]

Python évalue l'expression de manière répétée et, tant qu'elle est
vraie, exécute la première suite ; si l'expression est fausse (ce qui
peut arriver même lors du premier test), la suite de la clause "else",
si elle existe, est exécutée et la boucle se termine.

Une instruction "break" exécutée dans la première suite termine la
boucle sans exécuter la suite de la clause "else". Une instruction
"continue" exécutée dans la première suite saute le reste de la suite
et retourne au test de l'expression.


8.3. L'instruction "for"
========================

L'instruction "for" est utilisée pour itérer sur les éléments d'une
séquence (par exemple une chaîne, un *n*-uplet ou une liste) ou un
autre objet itérable :

   for_stmt: "for" target_list "in" starred_expression_list ":" suite
             ["else" ":" suite]

The "starred_expression_list" expression is evaluated once; it should
yield an *iterable* object. An *iterator* is created for that
iterable. The first item provided by the iterator is then assigned to
the target list using the standard rules for assignments (see Les
assignations), and the suite is executed. This repeats for each item
provided by the iterator. When the iterator is exhausted, the suite in
the "else" clause, if present, is executed, and the loop terminates.

Une instruction "break" exécutée dans la première suite termine la
boucle sans exécuter la suite de la clause "else". Une instruction
"continue" exécutée dans la première suite saute le reste de la suite
et continue avec l'élément suivant, ou avec la clause "else" s'il n'y
a pas d'élément suivant.

La boucle "for" effectue des affectations aux variables de la liste
cible, ce qui écrase toutes les affectations antérieures de ces
variables, y compris celles effectuées dans la suite de la boucle
"for" :

   for i in range(10):
       print(i)
       i = 5             # this will not affect the for-loop
                         # because i will be overwritten with the next
                         # index in the range

Les noms dans la liste cible ne sont pas supprimés lorsque la boucle
est terminée mais, si la séquence est vide, ils n'auront pas du tout
été assignés par la boucle. Petite astuce : le type natif "range()"
représente des suites arithmétiques immuables de nombres entiers ; par
exemple, itérer sur "range(3)" renvoie successivement les entiers 0, 1
et 2.

Modifié dans la version 3.11: les éléments étoilés sont maintenant
autorisés dans l'expression liste.


8.4. L'instruction "try"
========================

L'instruction "try" définit les gestionnaires d'exception ou le code
de nettoyage pour un groupe d'instructions :

   try_stmt:  try1_stmt | try2_stmt | try3_stmt
   try1_stmt: "try" ":" suite
              ("except" [expression ["as" identifier]] ":" suite)+
              ["else" ":" suite]
              ["finally" ":" suite]
   try2_stmt: "try" ":" suite
              ("except" "*" expression ["as" identifier] ":" suite)+
              ["else" ":" suite]
              ["finally" ":" suite]
   try3_stmt: "try" ":" suite
              "finally" ":" suite

Vous trouvez des informations supplémentaires relatives aux exceptions
dans la section Exceptions et, dans la section L'instruction raise,
des informations relatives à l'utilisation de l'instruction "raise"
pour produire des exceptions.

Modifié dans la version 3.14: Support for optionally dropping grouping
parentheses when using multiple exception types. See **PEP 758**.


8.4.1. clause "except"
----------------------

The "except" clause(s) specify one or more exception handlers. When no
exception occurs in the "try" clause, no exception handler is
executed. When an exception occurs in the "try" suite, a search for an
exception handler is started. This search inspects the "except"
clauses in turn until one is found that matches the exception. An
expression-less "except" clause, if present, must be last; it matches
any exception.

For an "except" clause with an expression, the expression must
evaluate to an exception type or a tuple of exception types.
Parentheses can be dropped if multiple exception types are provided
and the "as" clause is not used. The raised exception matches an
"except" clause whose expression evaluates to the class or a *non-
virtual base class* of the exception object, or to a tuple that
contains such a class.

Si aucune clause "except" ne correspond à l'exception, la recherche
d'un gestionnaire d'exception se poursuit dans le code englobant et
dans la pile d'appels. [1]

Si l'évaluation d'une expression dans l'en-tête d'une clause "except"
lève une exception, la recherche initiale d'un gestionnaire est
annulée et une recherche commence pour la nouvelle exception dans le
code englobant et dans la pile d'appels (c'est traité comme si
l'instruction "try" avait levé l'exception).

Lorsqu'une clause "except" correspond, l'exception est affectée à la
cible précisée après le mot-clé "as" dans cette clause "except", si
cette cible existe, et la suite de clause "except" est exécutée.
Toutes les clauses "except" doivent avoir un bloc exécutable. Lorsque
la fin de ce bloc est atteinte, l'exécution continue normalement après
l'ensemble de l'instruction "try" (cela signifie que si deux
gestionnaires imbriqués existent pour la même exception, et que
l'exception se produit dans la clause "try" du gestionnaire interne,
le gestionnaire externe ne gère pas l'exception).

Lorsqu'une exception a été affectée en utilisant "as cible", elle est
effacée à la fin de la clause "except". C'est comme si :

   except E as N:
       foo

avait été traduit en :

   except E as N:
       try:
           foo
       finally:
           del N

Cela veut dire que l'exception doit être assignée à un nom différent
pour pouvoir s'y référer après la clause "except". Les exceptions sont
effacées parce qu'avec la trace de la pile d'appels qui leur est
attachée, elles créent un cycle dans les pointeurs de références (avec
le cadre de la pile), ce qui conduit à conserver tous les noms locaux
de ce cadre en mémoire jusqu'au passage du ramasse-miettes.

Avant qu'une suite de clauses "except" ne soit exécutée, l'exception
est stockée dans le module "sys", où elle est accessible depuis le
corps de la clause "except" en appelant "sys.exception()". Lorsque
vous quittez un gestionnaire d'exceptions, l'exception stockée dans le
module "sys" est réinitialisée à sa valeur précédente :

   >>> print(sys.exception())
   None
   >>> try:
   ...     raise TypeError
   ... except:
   ...     print(repr(sys.exception()))
   ...     try:
   ...          raise ValueError
   ...     except:
   ...         print(repr(sys.exception()))
   ...     print(repr(sys.exception()))
   ...
   TypeError()
   ValueError()
   TypeError()
   >>> print(sys.exception())
   None


8.4.2. clause "except*"
-----------------------

The "except*" clause(s) specify one or more handlers for groups of
exceptions ("BaseExceptionGroup" instances). A "try" statement can
have either "except" or "except*" clauses, but not both. The exception
type for matching is mandatory in the case of "except*", so "except*:"
is a syntax error. The type is interpreted as in the case of "except",
but matching is performed on the exceptions contained in the group
that is being handled. An "TypeError" is raised if a matching type is
a subclass of "BaseExceptionGroup", because that would have ambiguous
semantics.

When an exception group is raised in the try block, each "except*"
clause splits (see "split()") it into the subgroups of matching and
non-matching exceptions. If the matching subgroup is not empty, it
becomes the handled exception (the value returned from
"sys.exception()") and assigned to the target of the "except*" clause
(if there is one). Then, the body of the "except*" clause executes. If
the non-matching subgroup is not empty, it is processed by the next
"except*" in the same manner. This continues until all exceptions in
the group have been matched, or the last "except*" clause has run.

After all "except*" clauses execute, the group of unhandled exceptions
is merged with any exceptions that were raised or re-raised from
within "except*" clauses. This merged exception group propagates on.:

   >>> try:
   ...     raise ExceptionGroup("eg",
   ...         [ValueError(1), TypeError(2), OSError(3), OSError(4)])
   ... except* TypeError as e:
   ...     print(f'caught {type(e)} with nested {e.exceptions}')
   ... except* OSError as e:
   ...     print(f'caught {type(e)} with nested {e.exceptions}')
   ...
   caught <class 'ExceptionGroup'> with nested (TypeError(2),)
   caught <class 'ExceptionGroup'> with nested (OSError(3), OSError(4))
     + Exception Group Traceback (most recent call last):
     |   File "<doctest default[0]>", line 2, in <module>
     |     raise ExceptionGroup("eg",
     |         [ValueError(1), TypeError(2), OSError(3), OSError(4)])
     | ExceptionGroup: eg (1 sub-exception)
     +-+---------------- 1 ----------------
       | ValueError: 1
       +------------------------------------

If the exception raised from the "try" block is not an exception group
and its type matches one of the "except*" clauses, it is caught and
wrapped by an exception group with an empty message string. This
ensures that the type of the target "e" is consistently
"BaseExceptionGroup":

   >>> try:
   ...     raise BlockingIOError
   ... except* BlockingIOError as e:
   ...     print(repr(e))
   ...
   ExceptionGroup('', (BlockingIOError(),))

"break", "continue" and "return" cannot appear in an "except*" clause.


8.4.3. clause "else"
--------------------

La clause optionnelle "else" n'est exécutée que si l'exécution atteint
la fin de la clause "try", aucune exception n'a été levée, et aucun
"return", "continue", ou "break" ont étés exécutés. Les exceptions
dans la clause "else" ne sont pas gérées par les clauses "except"
précédentes.


8.4.4. clause "finally"
-----------------------

If "finally" is present, it specifies a 'cleanup' handler.  The "try"
clause is executed, including any "except" and "else" clauses. If an
exception occurs in any of the clauses and is not handled, the
exception is temporarily saved. The "finally" clause is executed.  If
there is a saved exception it is re-raised at the end of the "finally"
clause. If the "finally" clause raises another exception, the saved
exception is set as the context of the new exception. If the "finally"
clause executes a "return", "break" or "continue" statement, the saved
exception is discarded. For example, this function returns 42.

   def f():
       try:
           1/0
       finally:
           return 42

L'information relative à l'exception n'est pas disponible pour le
programme pendant l'exécution de la clause "finally".

Lorsqu'une instruction "return", "break" ou "continue" est exécutée
dans la suite d'une instruction "try" d'une construction
"try"…"finally", la clause "finally" est aussi exécutée « à la sortie
».

The return value of a function is determined by the last "return"
statement executed.  Since the "finally" clause always executes, a
"return" statement executed in the "finally" clause will always be the
last one executed. The following function returns 'finally'.

   def foo():
       try:
           return 'try'
       finally:
           return 'finally'

Modifié dans la version 3.8: Avant Python 3.8, une instruction
"continue" n'était pas licite dans une clause "finally" en raison d'un
problème dans l'implémentation.

Modifié dans la version 3.14: The compiler emits a "SyntaxWarning"
when a "return", "break" or "continue" appears in a "finally" block
(see **PEP 765**).


8.5. L'instruction "with"
=========================

L'instruction "with" est utilisée pour encapsuler l'exécution d'un
bloc avec des méthodes définies par un gestionnaire de contexte (voir
la section Gestionnaire de contexte With). Cela permet d'utiliser de
manière simple le patron de conception classique
"try"…"except"…"finally".

   with_stmt:          "with" ( "(" with_stmt_contents ","? ")" | with_stmt_contents ) ":" suite
   with_stmt_contents: with_item ("," with_item)*
   with_item:          expression ["as" target]

L'exécution de l'instruction "with" avec un seul « élément » (*item*
dans la grammaire) se déroule comme suit :

1. L'expression de contexte (l'expression donnée dans le "with_item")
   est évaluée pour obtenir un gestionnaire de contexte.

2. The context manager's "__enter__()" is loaded for later use.

3. The context manager's "__exit__()" is loaded for later use.

4. The context manager's "__enter__()" method is invoked.

5. If a target was included in the "with" statement, the return value
   from "__enter__()" is assigned to it.

   Note:

     The "with" statement guarantees that if the "__enter__()" method
     returns without an error, then "__exit__()" will always be
     called. Thus, if an error occurs during the assignment to the
     target list, it will be treated the same as an error occurring
     within the suite would be. See step 7 below.

6. La suite est exécutée.

7. The context manager's "__exit__()" method is invoked.  If an
   exception caused the suite to be exited, its type, value, and
   traceback are passed as arguments to "__exit__()". Otherwise, three
   "None" arguments are supplied.

   If the suite was exited due to an exception, and the return value
   from the "__exit__()" method was false, the exception is reraised.
   If the return value was true, the exception is suppressed, and
   execution continues with the statement following the "with"
   statement.

   If the suite was exited for any reason other than an exception, the
   return value from "__exit__()" is ignored, and execution proceeds
   at the normal location for the kind of exit that was taken.

Le code suivant :

   with EXPRESSION as TARGET:
       SUITE

est sémantiquement équivalent à :

   manager = (EXPRESSION)
   enter = type(manager).__enter__
   exit = type(manager).__exit__
   value = enter(manager)
   hit_except = False

   try:
       TARGET = value
       SUITE
   except:
       hit_except = True
       if not exit(manager, *sys.exc_info()):
           raise
   finally:
       if not hit_except:
           exit(manager, None, None, None)

Avec plus d'un élément, les gestionnaires de contexte sont traités
comme si plusieurs instructions "with" étaient imbriquées :

   with A() as a, B() as b:
       SUITE

est sémantiquement équivalent à :

   with A() as a:
       with B() as b:
           SUITE

Vous pouvez aussi écrire des gestionnaires de contexte sur plusieurs
lignes pour plus d'un élément si ceux-ci sont placés entre
parenthèses. Par exemple :

   with (
       A() as a,
       B() as b,
   ):
       SUITE

Modifié dans la version 3.1: Prise en charge de multiples expressions
de contexte.

Modifié dans la version 3.10: prise en charge des parenthèses pour
pouvoir écrire l'instruction sur plusieurs lignes.

Voir aussi:

  **PEP 343** — L'instruction "with"
     La spécification, les motivations et des exemples de
     l'instruction "with" en Python.


8.6. L'instruction "match"
==========================

Ajouté dans la version 3.10.

L'instruction *match* est utilisée pour le filtrage par motif. Sa
syntaxe est :

   match_stmt:   'match' subject_expr ":" NEWLINE INDENT case_block+ DEDENT
   subject_expr: `!star_named_expression` "," `!star_named_expressions`?
                 | `!named_expression`
   case_block:   'case' patterns [guard] ":" `!block`

Note:

  cette section utilise les guillemets simples pour désigner les mots-
  clés ad-hoc.

Le filtrage par motif prend un motif en entrée ("pattern" après
"case") et un champ de recherche ("subject_expr" après "match"). Le
motif du filtre (qui peut contenir des sous-motifs de filtrage) est
confronté au contenu du champ de recherche. La sortie est composée de
:

* un indicateur de réussite ou d'échec pour le filtrage (on peut aussi
  dire que le motif a réussi ou échoué) ;

* la possibilité de lier les valeurs filtrées à un nom. Les pré-requis
  sont indiqués plus bas.

Les mots-clés "match" et "case" sont des mots-clés ad-hoc.

Voir aussi:

  * **PEP 634** — Spécifications pour le filtrage par motif

  * **PEP 636** — Tutoriel pour le filtrage par motif


8.6.1. Aperçu
-------------

Voici un aperçu du déroulement logique d'un filtrage par motif :

1. L'expression confrontée aux filtres, "subject_expr", est évaluée
   pour obtenir la valeur résultante. Si l'expression contient une
   virgule, un *n*-uplet est construit en utilisant les règles
   classiques.

2. Chaque filtre des blocs "case_block" est confronté à la valeur
   résultante du champ de recherche. Les règles particulières pour la
   réussite ou l'échec sont décrites plus bas. La confrontation du
   filtre peut aussi conduire à lier un ou plusieurs noms présents
   dans le motif. Les règles pour lier les noms des motifs dépendent
   du type de filtre et sont décrites plus bas. **Le nommage effectué
   lors d'un filtrage par motif qui a réussi persiste à l'extérieur du
   bloc et le nom peut être utilisé après l'instruction** "match".

   Note:

     en cas d'échec de la recherche, certains sous-filtres peuvent
     avoir réussi. Ne vous fiez pas aux nommages faits lors d'un
     filtrage qui a échoué. Inversement, ne vous fiez pas aux
     variables qui restent inchangées après un filtrage infructueux.
     Le comportement exact dépend de l'implémentation et peut varier.
     Il s'agit d'un choix intentionnel afin de permettre aux
     implémentations d'ajouter des optimisations.

3. Si la recherche réussit, la garde correspondante (si elle existe)
   est évaluée. Dans ce cas, on est sûr que les nommages ont bien eu
   lieu.

   * Si la garde s'évalue à vrai ou s'il n'y a pas de garde, le
     "block" à l'intérieur du "case_block" est exécuté.

   * Sinon, le "case_block" est testé comme décrit ci-dessus.

   * S'il n'y a plus de bloc "case_block", l'instruction est terminée.

Note:

  l'utilisateur ne doit jamais faire confiance à un filtre en cours
  d'évaluation. En fonction de l'implémentation, l'interpréteur peut
  mettre des valeurs en cache ou utiliser des optimisations qui
  évitent des réévaluations.

Voici un exemple d'instruction de filtrage par motif :

   >>> flag = False
   >>> match (100, 200):
   ...    case (100, 300):  # Mismatch: 200 != 300
   ...        print('Case 1')
   ...    case (100, 200) if flag:  # Successful match, but guard fails
   ...        print('Case 2')
   ...    case (100, y):  # Matches and binds y to 200
   ...        print(f'Case 3, y: {y}')
   ...    case _:  # Pattern not attempted
   ...        print('Case 4, I match anything!')
   ...
   Case 3, y: 200

Dans cet exemple, "if flag" est une garde. Plus de détails sont
fournis dans la prochaine section.


8.6.2. Gardes
-------------

   guard: "if" `!named_expression`

Une garde ("guard" qui fait partie du "case") doit s'évaluer à vrai
pour que le code à l'intérieur du bloc "case" soit exécuté. Elle
s'écrit sous la forme du mot-clé "if" suivi d'une expression.

Le déroulement logique d'un bloc "case" qui comprend une garde est le
suivant :

1. Vérification que le filtrage dans le bloc "case" est fructueux. Si
   le filtrage échoue, la garde n'est pas évaluée et on passe au bloc
   "case" suivant.

2. Si le filtrage est fructueux, évaluation de la garde.

   * Si la garde s'évalue à *vrai*, le bloc est sélectionné.

   * Si la garde s'évalue à *faux*, le bloc n'est pas sélectionné.

   * Si une exception est levée lors de l'évaluation de la garde,
     cette exception est propagée.

Les gardes étant des expressions, il est possible qu'elles aient des
effets secondaires. L'ordre d'évaluation des gardes est du premier au
dernier bloc "case", un à la fois, en sautant les blocs "case" dont la
recherche de motif échouent. L'évaluation des gardes s'arrête dès
qu'un bloc "case" est sélectionné.


8.6.3. Bloc "case" attrape-tout
-------------------------------

Un bloc "case" attrape-tout est un bloc qui réussit toujours. Une
instruction "match" ne peut avoir qu'un seul bloc attrape-tout, et ce
doit être le dernier.

Un bloc "case" est considéré attrape-tout s'il n'y a pas de garde et
que le motif est attrape-tout. Un motif est attrape-tout si l'on peut
déterminer, simplement à partir de sa syntaxe, qu'il correspond
toujours. Seuls les motifs suivants sont attrape-tout :

* Les Filtres AS pour lesquels la partie gauche est attrape-tout

* Les Filtres OU contenant au moins un filtre attrape-tout

* Les Filtres de capture

* Les Filtres attrape-tout

* les filtres attrape-tout entre parenthèses


8.6.4. Filtres
--------------

Note:

  Cette section utilise des notations grammaticales qui ne font pas
  partie du standard EBNF :

  * la notation "SEP.REGLE+" désigne "REGLE (SEP REGLE)*"

  * la notation "!REGLE" désigne la négation logique de l'assertion
    "REGLE"

La syntaxe générale pour les filtres "patterns" est :

   patterns:       open_sequence_pattern | pattern
   pattern:        as_pattern | or_pattern
   closed_pattern: | literal_pattern
                   | capture_pattern
                   | wildcard_pattern
                   | value_pattern
                   | group_pattern
                   | sequence_pattern
                   | mapping_pattern
                   | class_pattern

Les explications ci-dessous décrivent « en termes simples » ce qu'un
modèle fait (merci à Raymond Hettinger pour son document qui a inspiré
la plupart des descriptions). Notez que ces descriptions sont purement
à fin d'illustration et peuvent ne **pas** être strictement conformes
à l'implémentation sous-jacente. De plus, nous ne couvrons pas toutes
les formes valides.


8.6.4.1. Filtres OU
~~~~~~~~~~~~~~~~~~~

Un filtre OU est composé de deux filtres ou plus séparés par des
barres verticales "|". La syntaxe est :

   or_pattern: "|".closed_pattern+

Seul le dernier sous-filtre peut être attrape-tout et chaque sous-
filtre doit être lié au même ensemble de noms pour éviter toute
ambigüité.

Un filtre OU confronte chacun des sous-filtres à tour de rôle à la
valeur du champ de recherche, jusqu'à ce que l'un d'eux réussisse. Le
filtre OU réussit si l'un des sous-filtres a réussi, sinon il échoue.

En termes plus simples, "M1 | M2 | ..." teste le filtre par motif
"M1", s'il échoue il teste le filtre par motif "M2", réussit
immédiatement si l'un d'eux réussit, échoue dans le cas contraire.


8.6.4.2. Filtres AS
~~~~~~~~~~~~~~~~~~~

Un filtre AS confronte un filtre OU sur la gauche du mot-clé "as" au
champ de recherche. La syntaxe est la suivante :

   as_pattern: or_pattern "as" capture_pattern

Si le filtre OU échoue, le filtre AS échoue. Sinon, le filtre AS lie
le champ de recherche au nom sur la droite du mot-clé "as" et réussit.
"capture_pattern" ne peut pas être un "_".

En termes simples, "M as NOM" filtre avec le motif "M" et, s'il
réussit, définit "NOM = <subject>".


8.6.4.3. Filtres littéraux
~~~~~~~~~~~~~~~~~~~~~~~~~~

Un filtre littéral effectue une correspondance avec la plupart des
littéraux en Python. La syntaxe est la suivante :

   literal_pattern: signed_number
                    | signed_number "+" NUMBER
                    | signed_number "-" NUMBER
                    | strings
                    | "None"
                    | "True"
                    | "False"
   signed_number:   ["-"] NUMBER

The rule "strings" and the token "NUMBER" are defined in the standard
Python grammar.  Triple-quoted strings are supported.  Raw strings and
byte strings are supported.  f-strings and t-strings are not
supported.

Les formes "signed_number '+' NUMBER" et "signed_number '-' NUMBER"
permettent d'exprimer des nombres complexes ; vous devez indiquer un
nombre réel sur la gauche et un nombre imaginaire sur la droite. Par
exemple, "3 + 4j".

En termes simples, "LITERAL" réussit seulement si "<subject> ==
LITERAL". Pour les singletons "None", "True" et "False", l'opérateur
"is" est utilisé.


8.6.4.4. Filtres de capture
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un filtre de capture lie la valeur du champ de recherche à un nom. La
syntaxe est la suivante :

   capture_pattern: !'_' NAME

Un simple caractère souligné "_" n'est pas un filtre de capture (c'est
ce que "!'_'" veut dire). C'est le motif pour désigner un filtre
attrape-tout (lexème "wilcard_pattern", voir plus bas).

Dans un filtre donné, un nom ne peut être lié qu'une seule fois. Par
exemple, "case x, x: ..." est invalide mais "case [x] | x: ..." est
autorisé.

Les filtres de capture réussissent toujours. La portée du lien est
conforme aux règles définies pour l'opérateur d'affectation indiquées
dans la **PEP 572** ; le nom devient une variable locale dans la
fonction la plus intérieure à moins qu'il n'y ait une instruction
"global" ou "nonlocal" qui s'applique.

En termes simples, "NAME" réussit toujours et définit "NAME =
<subject>".


8.6.4.5. Filtres attrape-tout
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un filtre attrape-tout réussit toujours (quel que soit le champ de
recherche) et ne lie aucun nom. La syntaxe est la suivante :

   wildcard_pattern: '_'

"_" est un mot-clé ad-hoc dans un filtre par motif, mais seulement
dans un filtre. Ailleurs, c'est un identifiant, comme d'habitude, même
à l'intérieur d'une expression champ de recherche de "match", d'une
garde ou d'un bloc "case".

En termes simples, "_" réussit toujours.


8.6.4.6. Filtres par valeurs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un filtre par valeur représente une valeur nommée de Python. Sa
syntaxe est la suivante :

   value_pattern: attr
   attr:          name_or_attr "." NAME
   name_or_attr:  attr | NAME

Le nom qualifié dans le filtre est recherché en utilisant la méthode
de résolution des noms standard de Python. Le filtrage réussit si la
valeur trouvée vérifie l'égalité avec la valeur du champ de recherche
(en utilisant l'opérateur d'égalité "==").

En termes plus simples, "NOM1.NOM2" réussit seulement si "<subject> ==
NOM1.NOM2"

Note:

  si la même valeur apparaît plusieurs fois dans la même instruction
  "match", l'interpréteur peut mettre en cache la première valeur
  trouvée et la réutiliser plutôt que de refaire une recherche. Ce
  cache est strictement limité à l'exécution de l'instruction "match"
  donnée.


8.6.4.7. Filtres de groupes
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un filtre de groupe permet au programmeur de souligner l’intention de
regrouper des motifs en plaçant ceux-ci entre parenthèses. À part ça,
il n’introduit aucune syntaxe supplémentaire. Sa syntaxe est la
suivante :

   group_pattern: "(" pattern ")"

En termes plus simples, "(P)" équivaut à "P".


8.6.4.8. Filtres de séquences
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un filtre de séquence contient des sous-filtres par motif dont chacun
doit correspondre à un élément d’une séquence. La syntaxe est
similaire au déballage d’une liste ou d’un *n*-uplet.

   sequence_pattern:       "[" [maybe_sequence_pattern] "]"
                           | "(" [open_sequence_pattern] ")"
   open_sequence_pattern:  maybe_star_pattern "," [maybe_sequence_pattern]
   maybe_sequence_pattern: ",".maybe_star_pattern+ ","?
   maybe_star_pattern:     star_pattern | pattern
   star_pattern:           "*" (capture_pattern | wildcard_pattern)

Vous pouvez utiliser indifféremment des parenthèses "(...)" ou des
crochets "[...]" pour encadrer les filtres à regrouper.

Note:

  un filtre seul entre parenthèses qui ne se termine pas par une
  virgule (par exemple "(3 | 4)") est un filtre de groupe. En
  revanche, un filtre seul entre crochets (par exemple "[3 | 4]")
  reste un filtre de séquence.

Il peut y avoir au plus un sous-filtre étoilé (lexème "star_pattern")
dans un filtre de séquence. Le filtre étoilé peut se trouver à
n’importe quelle position. S’il n’y en a pas, le filtre de séquence
est un filtre de séquence à longueur fixe, sinon c’est un filtre de
séquence à longueur variable.

Voici le déroulement logique d’un filtrage par motif de séquence sur
une valeur du champ de recherche :

1. Si la valeur du champ de recherche n’est pas une séquence [2], le
   filtre de séquence échoue.

2. Si la valeur du champ de recherche est une instance de "str",
   "bytes" ou "bytearray", le filtre de séquence échoue.

3. Les étapes suivantes dépendent de la longueur fixe ou non du filtre
   de séquence.

   Si le filtre de séquence est de longueur fixe :

   1. Si la longueur de la séquence champ de recherche n’est pas égale
      au nombre de sous-filtres, le filtre de séquence échoue.

   2. Les sous-filtres de la séquence sont confrontés aux éléments
      correspondants dans la séquence champ de recherche, de la gauche
      vers la droite. La recherche de correspondance s’arrête dès
      qu’un sous-filtre échoue. Si tous les sous-filtres réussissent
      la confrontation à l’élément du champ de recherche
      correspondant, le filtre de séquence réussit.

   Sinon, si le filtre de séquence est de longueur variable :

   1. Si la longueur de la séquence champ de recherche est plus petite
      que le nombre de sous-filtres sans étoile, le filtre de séquence
      échoue.

   2. Les sous-filtres sans étoile du début sont confrontés aux
      éléments correspondants comme pour un filtre de séquences de
      longueur fixe.

   3. Si les étapes précédentes ont réussi, le sous-filtre étoilé
      correspond à une liste formée des éléments restants du champ de
      recherche, en excluant les éléments restants qui correspondent à
      des sous-filtres sans étoile qui suivent le sous-filtre étoilé.

   4. Les sous-filtres sans étoile qui restent sont confrontés aux
      éléments restants du champ de recherche, comme pour un filtre de
      séquences de longueur fixe.

   Note:

     The length of the subject sequence is obtained via "len()" (i.e.
     via the "__len__()" protocol). This length may be cached by the
     interpreter in a similar manner as value patterns.

En termes plus simples, "[M1, M2, M3," … ", M<N>]" réussit seulement
si tout ce qui suit a lieu :

* vérification que "<subject>" est une séquence,

* "len(subject) == <N>",

* "M1" correspond à "<subject>[0]" (notez que cette correspondance
  peut lier des noms),

* "M2" correspond à "<subject>[1]" (notez que cette correspondance
  peut lier des noms),

* et ainsi de suite pour chaque filtre par motif / élément.


8.6.4.9. Filtres associatifs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un filtre associatif contient un ou plusieurs motifs clé-valeur. La
syntaxe est similaire à la construction d’un dictionnaire :

   mapping_pattern:     "{" [items_pattern] "}"
   items_pattern:       ",".key_value_pattern+ ","?
   key_value_pattern:   (literal_pattern | value_pattern) ":" pattern
                        | double_star_pattern
   double_star_pattern: "**" capture_pattern

Un seul sous-filtre doublement étoilé peut être présent dans le filtre
associatif. Le filtre doublement étoilé doit être le dernier sous-
filtre du filtre associatif.

Il est interdit d’avoir des clés en double dans les filtres
associatifs. Une clé en double sous forme littérale lève une "Syntax
Error". Deux clés qui ont la même valeur lèvent une "ValueError" à
l’exécution.

Voici le déroulement d’un filtrage associatif sur la valeur du champ
de recherche :

1. Si la valeur du champ de recherche n'est pas un tableau associatif
   [3], le filtre associatif échoue.

2. Si chaque clé donnée dans le filtre associatif est présente dans le
   tableau associatif du champ de recherche, et que le filtre pour
   chaque clé correspond aux éléments du tableau associatif champ de
   recherche, le filtre associatif réussit.

3. Si des clés identiques sont détectées dans le filtre par motif, le
   filtre est déclaré invalide. Une "SyntaxError" est levée pour les
   valeurs littérales dupliquées ou une "ValueError" pour des clés
   s'évaluant à la même valeur.

Note:

  Key-value pairs are matched using the two-argument form of the
  mapping subject's "get()" method.  Matched key-value pairs must
  already be present in the mapping, and not created on-the-fly via
  "__missing__()" or "__getitem__()".

En termes simples, "{CLÉ1: M1, CLÉ2: M2, ... }" réussit seulement si
tout ce qui suit a lieu :

* vérification que "<subject>" est un tableau associatif,

* "CLÉ1 in <subject>",

* "M1" correspond à "<subject>[CLÉ1]",

* et ainsi de suite pour chaque paire CLÉ/Motif.


8.6.4.10. Filtres de classes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un filtre de classe représente une classe et ses arguments
positionnels et par mots-clés (s'il y en a). La syntaxe est la
suivante :

   class_pattern:       name_or_attr "(" [pattern_arguments ","?] ")"
   pattern_arguments:   positional_patterns ["," keyword_patterns]
                        | keyword_patterns
   positional_patterns: ",".pattern+
   keyword_patterns:    ",".keyword_pattern+
   keyword_pattern:     NAME "=" pattern

Le même mot-clé ne doit pas être répété dans les filtres de classes.

Voici le déroulement d’un filtrage de classe sur la valeur du champ de
recherche :

1. Si "name_or_attr" n'est pas une instance de la classe native
   "type", lève une "TypeError".

2. Si la valeur du champ de recherche n'est pas une instance de
   "name_or_attr" (testé *via* "isinstance()"), le filtre de classe
   échoue.

3. S'il n'y a pas d'argument au filtre, le filtre réussit. Sinon, les
   étapes suivantes dépendent de la présence ou non de motifs pour les
   arguments positionnels ou par mot-clé.

   Pour un certain nombre de types natifs (indiqués ci-dessous), un
   motif positionnel seul est accepté, qui est confronté au champ de
   recherche en entier ; pour ces types, les motifs par mots-clés
   fonctionnent comme les autres types.

   S'il n'y a que des motifs par mot-clé (NdT : dans le sens «
   argument par mot-clé »), ils sont évalués comme ceci, un par un :

   1. The keyword is looked up as an attribute on the subject.

      * Si cela lève une exception autre que "AttributeError",
        l'exception est propagée vers le haut.

      * Si cela lève l'exception "AttributeError", le filtre échoue.

      * Sinon, le motif associé au mot-clé est confronté à la valeur
        de l'attribut du champ de recherche. Si cela échoue, le filtre
        de classe échoue ; si cela réussit, le filtre passe au mot-clé
        suivant.

   2. If all keyword patterns succeed, the class pattern succeeds.

   Si des motifs positionnels sont présents, ils sont convertis en
   motifs par mot-clé en utilisant l'attribut "__match_args__" de la
   classe "name_or_attr" avant le filtrage :

   1. The equivalent of "getattr(cls, "__match_args__", ())" is
      called.

      * Si cela lève une exception, elle est propagée vers le haut.

      * Si la valeur de retour n'est pas un *n*-uplet, la conversion
        échoue et une "TypeError" est levée.

      * S'il y a plus de motifs positionnels que
        "len(cls.__match_args__)", une "TypeError" est levée.

      * Sinon, le motif positionnel "i" est converti en motif par mot-
        clé (le mot-clé sera "__match_args__[i]"). "__match_args__[i]"
        doit être une chaîne, sinon une "TypeError" est levée.

      * Si un mot-clé est dupliqué, une "TypeError" est levée.

      Voir aussi:

        Arguments positionnels dans le filtrage par motif sur les
        classes

   2. Once all positional patterns have been converted to keyword
      patterns, the match proceeds as if there were only keyword
      patterns.

   Pour les types natifs suivants, le traitement des motifs
   positionnels est différent :

   * "bool"

   * "bytearray"

   * "bytes"

   * "dict"

   * "float"

   * "frozenset"

   * "int"

   * "list"

   * "set"

   * "str"

   * "tuple"

   Ces classes acceptent un argument positionnel seul et le filtre
   s'applique alors sur l'ensemble de l'objet plutôt que sur un simple
   attribut. Par exemple, "int(0|1)" réussit lorsqu'il est confronté à
   la valeur "0", mais pas lorsque c'est la valeur "0.0".

En termes simples, "CLS(P1, attr=P2)" réussit seulement si la séquence
suivante est déroulée :

* "isinstance(<subject>, CLS)"

* convertit "P1" vers un motif par mot-clé en utilisant
  "CLS.__match_args__"

* Pour chaque argument par mot-clé "attr=P2" :

  * "hasattr(<subject>, "attr")"

  * "P2" correspond à "<subject>.attr"

* … et ainsi de suite pour les paires motif/argument par mot-clé.

Voir aussi:

  * **PEP 634** — Spécifications pour le filtrage par motif

  * **PEP 636** — Tutoriel pour le filtrage par motif


8.7. Définition de fonctions
============================

Une définition de fonction définit un objet fonction défini par
l'utilisateur (voir la section Hiérarchie des types standards) :

   funcdef:                   [decorators] "def" funcname [type_params] "(" [parameter_list] ")"
                              ["->" expression] ":" suite
   decorators:                decorator+
   decorator:                 "@" assignment_expression NEWLINE
   parameter_list:            defparameter ("," defparameter)* "," "/" ["," [parameter_list_no_posonly]]
                                | parameter_list_no_posonly
   parameter_list_no_posonly: defparameter ("," defparameter)* ["," [parameter_list_starargs]]
                              | parameter_list_starargs
   parameter_list_starargs:   "*" [star_parameter] ("," defparameter)* ["," [parameter_star_kwargs]]
                              | "*" ("," defparameter)+ ["," [parameter_star_kwargs]]
                              | parameter_star_kwargs
   parameter_star_kwargs:     "**" parameter [","]
   parameter:                 identifier [":" expression]
   star_parameter:            identifier [":" ["*"] expression]
   defparameter:              parameter ["=" expression]
   funcname:                  identifier

Une définition de fonction est une instruction qui est exécutée. Son
exécution lie le nom de la fonction, dans l'espace de nommage local
courant, à un objet fonction (un objet qui encapsule le code
exécutable de la fonction). Cet objet fonction contient une référence
à l'espace des noms globaux courant comme espace des noms globaux à
utiliser lorsque la fonction est appelée.

La définition de la fonction n'exécute pas le corps de la fonction ;
elle n'est exécutée que lorsque la fonction est appelée. [4]

Une définition de fonction peut être encapsulée dans une ou plusieurs
expressions *decorator* ; les décorateurs sont évalués lorsque la
fonction est définie, dans la portée qui contient la définition de
fonction ; le résultat doit être un appelable, qui est invoqué avec
l'objet fonction comme seul argument ; la valeur renvoyée est liée au
nom de la fonction en lieu et place de l'objet fonction. Lorsqu'il y a
plusieurs décorateurs, ils sont appliqués par imbrication ; par
exemple, le code suivant :

   @f1(arg)
   @f2
   def func(): pass

est à peu près équivalent à :

   def func(): pass
   func = f1(arg)(f2(func))

sauf que la fonction originale n'est pas temporairement liée au nom
"func".

Modifié dans la version 3.9: les fonctions peuvent être décorées par
toute "expression d'affectation" valide. Auparavant, la grammaire
était beaucoup plus restrictive ; voir la **PEP 614** pour obtenir les
détails.

A list of type parameters may be given in square brackets between the
function's name and the opening parenthesis for its parameter list.
This indicates to static type checkers that the function is generic.
At runtime, the type parameters can be retrieved from the function's
"__type_params__" attribute. See Generic functions for more.

Modifié dans la version 3.12: Type parameter lists are new in Python
3.12.

Lorsqu'un ou plusieurs *paramètres* sont de la forme *parameter* "="
*expression*, on dit que la fonction a des « valeurs de paramètres par
défaut ». Pour un paramètre avec une valeur par défaut, l’*argument*
correspondant peut être omis lors de l'appel, la valeur par défaut du
paramètre est alors utilisée. Si un paramètre a une valeur par défaut,
tous les paramètres suivants jusqu'à ""*"" doivent aussi avoir une
valeur par défaut — ceci est une restriction syntaxique qui n'est pas
exprimée dans la grammaire.

**Les valeurs par défaut des paramètres sont évaluées de la gauche
vers la droite quand la définition de la fonction est exécutée**. Cela
signifie que l'expression est évaluée une fois, lorsque la fonction
est définie, et que c'est la même valeur « pré-calculée » qui est
utilisée à chaque appel. C'est particulièrement important à comprendre
lorsque la valeur d'un paramètre par défaut est un objet mutable (cas
d'une liste ou un dictionnaire par exemple) : si la fonction modifie
l'objet (par exemple en ajoutant un élément à une liste), la valeur
par défaut est modifiée. En général, ce n'est pas l'effet voulu. Une
façon d'éviter cet écueil est d'utiliser "None" par défaut et de
tester explicitement la valeur dans le corps de la fonction. Par
exemple :

   def whats_on_the_telly(penguin=None):
       if penguin is None:
           penguin = []
       penguin.append("property of the zoo")
       return penguin

La sémantique de l'appel de fonction est décrite plus en détail dans
la section Appels. Un appel de fonction assigne toujours des valeurs à
tous les paramètres mentionnés dans la liste des paramètres, soit à
partir d'arguments positionnels, d'arguments par mots-clés ou de
valeurs par défaut. S'il y a un paramètre de la forme "*identifier",
il est initialisé à un *n*-uplet recevant les paramètres positionnels
en surplus, la valeur par défaut étant le *n*-uplet vide. S'il y a un
paramètre de la forme "**identifier", il est initialisé à un nouveau
tableau associatif ordonné qui récupère tous les arguments par mot-clé
en surplus, la valeur par défaut étant un tableau associatif vide du
même type. Les paramètres après "*" ou "*identifier" sont forcément
des paramètres par mot-clé et ne peuvent être passés qu'en utilisant
des arguments par mot-clé. Au contraire, ceux avant "/" ne peuvent
être passés qu'avec des arguments positionnels.

Modifié dans la version 3.8: ajout de la syntaxe avec "/" pour
indiquer les paramètre exclusivement positionnels (voir la **PEP
570**).

Parameters may have an *annotation* of the form "": expression""
following the parameter name.  Any parameter may have an annotation,
even those of the form "*identifier" or "**identifier". (As a special
case, parameters of the form "*identifier" may have an annotation "":
*expression"".) Functions may have "return" annotation of the form
""-> expression"" after the parameter list.  These annotations can be
any valid Python expression.  The presence of annotations does not
change the semantics of a function. See Annotations for more
information on annotations.

Modifié dans la version 3.11: Parameters of the form ""*identifier""
may have an annotation "": *expression"". See **PEP 646**.

Il est aussi possible de créer des fonctions anonymes (fonctions non
liées à un nom), pour une utilisation immédiate dans des expressions.
Utilisez alors des expressions lambda, décrites dans la section
Expressions lambda. Notez qu'une expression lambda est simplement un
raccourci pour définir une fonction simple ; une fonction définie par
une instruction ""def"" peut être passée (en argument) ou assignée à
un autre nom, tout comme une fonction définie par une expression
lambda. La forme ""def"" est en fait plus puissante puisqu'elle permet
l'exécution de plusieurs instructions et les annotations.

**Note pour les programmeurs :** les fonctions sont des objets de
première classe. Une instruction ""def"" exécutée à l'intérieur d'une
définition de fonction définit une fonction locale qui peut être
renvoyée ou passée en tant qu'argument. Les variables libres utilisées
dans la fonction imbriquée ont accès aux variables locales de la
fonction contenant le ""def"".  Voir la section Noms et liaisons pour
plus de détails.

Voir aussi:

  **PEP 3107** — Annotations de fonctions
     La spécification originale pour les annotations de fonctions.

  **PEP 484** — Indications de types
     Définition de la signification standard pour les annotations :
     indications de types.

  **PEP 526** — Syntaxe pour les annotations de variables
     Ability to type hint variable declarations, including class
     variables and instance variables.

  **PEP 563** — Évaluation différée des annotations
     Gestion des références postérieures à l'intérieur des annotations
     en préservant les annotations sous forme de chaînes à l'exécution
     au lieu d'une évaluation directe.

  **PEP 318** - Decorators for Functions and Methods
     Function and method decorators were introduced. Class decorators
     were introduced in **PEP 3129**.


8.8. Définition de classes
==========================

Une définition de classe définit un objet classe (voir la section
Hiérarchie des types standards) :

   classdef:    [decorators] "class" classname [type_params] [inheritance] ":" suite
   inheritance: "(" [argument_list] ")"
   classname:   identifier

Une définition de classe est une instruction qui est exécutée. La
liste d'héritage (*inheritance* entre crochets dans la grammaire ci-
dessus) donne habituellement une liste de classes mères (voir
Métaclasses pour des utilisations plus avancées). Donc chaque élément
de la liste doit pouvoir être évalué comme un objet classe qui
autorise les sous-classes. Les classes sans liste d'héritage héritent,
par défaut, de la classe mère "object" ; d'où :

   class Foo:
       pass

est équivalente à :

   class Foo(object):
       pass

La suite de la classe est ensuite exécutée dans un nouveau cadre
d'exécution (voir Noms et liaisons), en utilisant un espace de nommage
local nouvellement créé et l'espace de nommage global d'origine
(habituellement, la suite contient principalement des définitions de
fonctions). Lorsque la suite de la classe termine son exécution, son
cadre d'exécution est abandonné mais son espace des noms locaux est
sauvegardé [5]. Un objet classe est alors créé en utilisant la liste
d'héritage pour les classes mères et l'espace de nommage sauvegardé
comme dictionnaire des attributs. Le nom de classe est lié à l'objet
classe dans l'espace de nommage local original.

The order in which attributes are defined in the class body is
preserved in the new class's "__dict__".  Note that this is reliable
only right after the class is created and only for classes that were
defined using the definition syntax.

La création de classes peut être fortement personnalisée en utilisant
les métaclasses.

Les classes peuvent aussi être décorées. Comme pour les décorateurs de
fonctions :

   @f1(arg)
   @f2
   class Foo: pass

est à peu près équivalent à :

   class Foo: pass
   Foo = f1(arg)(f2(Foo))

Les règles d'évaluation pour les expressions de décorateurs sont les
mêmes que pour les décorateurs de fonctions. Le résultat est alors lié
au nom de la classe.

Modifié dans la version 3.9: les classes peuvent être décorées par
toute "expression d'affectation" valide. Auparavant, la grammaire
était beaucoup plus restrictive ; voir la **PEP 614** pour obtenir les
détails.

A list of type parameters may be given in square brackets immediately
after the class's name. This indicates to static type checkers that
the class is generic. At runtime, the type parameters can be retrieved
from the class's "__type_params__" attribute. See Generic classes for
more.

Modifié dans la version 3.12: Type parameter lists are new in Python
3.12.

**Note pour les programmeurs :** les variables définies dans la
définition de classe sont des attributs de classe ; elles sont
partagées par les instances. Les attributs d'instance peuvent être
définis dans une méthode en utilisant "self.name = value". Les
attributs de classe et d'instance sont accessibles par la notation
""self.name"", et un attribut d'instance masque un attribut de classe
de même nom lorsqu'on y accède de cette façon. Les attributs de classe
peuvent être utilisés comme valeurs par défaut pour les attributs
d'instances, mais l'utilisation de valeurs mutables peut conduire à
des résultats inattendus. Les descripteurs peuvent être utilisés pour
créer des variables d'instances avec des détails d'implémentation
différents.

Voir aussi:

  **PEP 3115** — Métaclasses dans Python 3000
     La proposition qui a modifié la déclaration de métaclasses à la
     syntaxe actuelle, et la sémantique pour la façon dont les classes
     avec métaclasses sont construites.

  **PEP 3129** — Décorateurs de classes
     La proposition qui a ajouté des décorateurs de classe. Les
     décorateurs de fonction et de méthode ont été introduits dans
     **PEP 318**.


8.9. Coroutines
===============

Ajouté dans la version 3.5.


8.9.1. Définition de fonctions coroutines
-----------------------------------------

   async_funcdef: [decorators] "async" "def" funcname "(" [parameter_list] ")"
                  ["->" expression] ":" suite

L'exécution de coroutines Python peut être suspendue et reprise à
plusieurs endroits (voir *coroutine*). Les expressions "await", "async
for" et "async with" ne peuvent être utilisées que dans les corps de
coroutines.

Les fonctions définies avec la syntaxe "async def" sont toujours des
fonctions coroutines, même si elles ne contiennent aucun mot-clé
"await" ou "async".

C'est une "SyntaxError" d'utiliser une expression "yield from" dans
une coroutine.

Un exemple de fonction coroutine :

   async def func(param1, param2):
       do_stuff()
       await some_coroutine()

Modifié dans la version 3.7: "await" et "async" sont dorénavant des
mots-clés ; auparavant, ils n'étaient traités comme tels que dans le
corps d'une fonction coroutine.


8.9.2. L'instruction "async for"
--------------------------------

   async_for_stmt: "async" for_stmt

Un *itérable asynchrone* fournit une méthode "__aiter__" qui renvoie
directement un *itérateur asynchrone*, celui-ci pouvant appeler du
code asynchrone dans sa méthode "__anext__".

L'instruction "async for" permet d'itérer facilement sur des itérables
asynchrones.

Le code suivant :

   async for TARGET in ITER:
       SUITE
   else:
       SUITE2

est sémantiquement équivalent à :

   iter = (ITER)
   iter = type(iter).__aiter__(iter)
   running = True

   while running:
       try:
           TARGET = await type(iter).__anext__(iter)
       except StopAsyncIteration:
           running = False
       else:
           SUITE
   else:
       SUITE2

Voir aussi "__aiter__()" et "__anext__()" pour plus de détails.

C'est une "SyntaxError" d'utiliser une instruction "async for" en
dehors d'une fonction coroutine.


8.9.3. L'instruction "async with"
---------------------------------

   async_with_stmt: "async" with_stmt

Un *gestionnaire de contexte asynchrone* est un *gestionnaire de
contexte* qui est capable de suspendre l'exécution dans ses méthodes
*enter* et *exit*.

Le code suivant :

   async with EXPRESSION as TARGET:
       SUITE

est sémantiquement équivalent à :

   manager = (EXPRESSION)
   aenter = type(manager).__aenter__
   aexit = type(manager).__aexit__
   value = await aenter(manager)
   hit_except = False

   try:
       TARGET = value
       SUITE
   except:
       hit_except = True
       if not await aexit(manager, *sys.exc_info()):
           raise
   finally:
       if not hit_except:
           await aexit(manager, None, None, None)

Voir aussi "__aenter__()" et "__aexit__()" pour plus de détails.

C'est une "SyntaxError" d'utiliser l'instruction "async with" en
dehors d'une fonction coroutine.

Voir aussi:

  **PEP 492** — Coroutines avec les syntaxes *async* et *await*
     La proposition qui a fait que les coroutines soient un concept
     propre en Python, et a ajouté la syntaxe de prise en charge de
     celles-ci.


8.10. Type parameter lists
==========================

Ajouté dans la version 3.12.

Modifié dans la version 3.13: Support for default values was added
(see **PEP 696**).

   type_params:  "[" type_param ("," type_param)* "]"
   type_param:   typevar | typevartuple | paramspec
   typevar:      identifier (":" expression)? ("=" expression)?
   typevartuple: "*" identifier ("=" expression)?
   paramspec:    "**" identifier ("=" expression)?

Functions (including coroutines), classes and type aliases may contain
a type parameter list:

   def max[T](args: list[T]) -> T:
       ...

   async def amax[T](args: list[T]) -> T:
       ...

   class Bag[T]:
       def __iter__(self) -> Iterator[T]:
           ...

       def add(self, arg: T) -> None:
           ...

   type ListOrSet[T] = list[T] | set[T]

Semantically, this indicates that the function, class, or type alias
is generic over a type variable. This information is primarily used by
static type checkers, and at runtime, generic objects behave much like
their non-generic counterparts.

Type parameters are declared in square brackets ("[]") immediately
after the name of the function, class, or type alias. The type
parameters are accessible within the scope of the generic object, but
not elsewhere. Thus, after a declaration "def func[T](): pass", the
name "T" is not available in the module scope. Below, the semantics of
generic objects are described with more precision. The scope of type
parameters is modeled with a special function (technically, an
annotation scope) that wraps the creation of the generic object.

Generic functions, classes, and type aliases have a "__type_params__"
attribute listing their type parameters.

Type parameters come in three kinds:

* "typing.TypeVar", introduced by a plain name (e.g., "T").
  Semantically, this represents a single type to a type checker.

* "typing.TypeVarTuple", introduced by a name prefixed with a single
  asterisk (e.g., "*Ts"). Semantically, this stands for a tuple of any
  number of types.

* "typing.ParamSpec", introduced by a name prefixed with two asterisks
  (e.g., "**P"). Semantically, this stands for the parameters of a
  callable.

"typing.TypeVar" declarations can define *bounds* and *constraints*
with a colon (":") followed by an expression. A single expression
after the colon indicates a bound (e.g. "T: int"). Semantically, this
means that the "typing.TypeVar" can only represent types that are a
subtype of this bound. A parenthesized tuple of expressions after the
colon indicates a set of constraints (e.g. "T: (str, bytes)"). Each
member of the tuple should be a type (again, this is not enforced at
runtime). Constrained type variables can only take on one of the types
in the list of constraints.

For "typing.TypeVar"s declared using the type parameter list syntax,
the bound and constraints are not evaluated when the generic object is
created, but only when the value is explicitly accessed through the
attributes "__bound__" and "__constraints__". To accomplish this, the
bounds or constraints are evaluated in a separate annotation scope.

"typing.TypeVarTuple"s and "typing.ParamSpec"s cannot have bounds or
constraints.

All three flavors of type parameters can also have a *default value*,
which is used when the type parameter is not explicitly provided. This
is added by appending a single equals sign ("=") followed by an
expression. Like the bounds and constraints of type variables, the
default value is not evaluated when the object is created, but only
when the type parameter's "__default__" attribute is accessed. To this
end, the default value is evaluated in a separate annotation scope. If
no default value is specified for a type parameter, the "__default__"
attribute is set to the special sentinel object "typing.NoDefault".

The following example indicates the full set of allowed type parameter
declarations:

   def overly_generic[
      SimpleTypeVar,
      TypeVarWithDefault = int,
      TypeVarWithBound: int,
      TypeVarWithConstraints: (str, bytes),
      *SimpleTypeVarTuple = (int, float),
      **SimpleParamSpec = (str, bytearray),
   ](
      a: SimpleTypeVar,
      b: TypeVarWithDefault,
      c: TypeVarWithBound,
      d: Callable[SimpleParamSpec, TypeVarWithConstraints],
      *e: SimpleTypeVarTuple,
   ): ...


8.10.1. Generic functions
-------------------------

Generic functions are declared as follows:

   def func[T](arg: T): ...

This syntax is equivalent to:

   annotation-def TYPE_PARAMS_OF_func():
       T = typing.TypeVar("T")
       def func(arg: T): ...
       func.__type_params__ = (T,)
       return func
   func = TYPE_PARAMS_OF_func()

Here "annotation-def" indicates an annotation scope, which is not
actually bound to any name at runtime. (One other liberty is taken in
the translation: the syntax does not go through attribute access on
the "typing" module, but creates an instance of "typing.TypeVar"
directly.)

The annotations of generic functions are evaluated within the
annotation scope used for declaring the type parameters, but the
function's defaults and decorators are not.

The following example illustrates the scoping rules for these cases,
as well as for additional flavors of type parameters:

   @decorator
   def func[T: int, *Ts, **P](*args: *Ts, arg: Callable[P, T] = some_default):
       ...

Except for the lazy evaluation of the "TypeVar" bound, this is
equivalent to:

   DEFAULT_OF_arg = some_default

   annotation-def TYPE_PARAMS_OF_func():

       annotation-def BOUND_OF_T():
           return int
       # In reality, BOUND_OF_T() is evaluated only on demand.
       T = typing.TypeVar("T", bound=BOUND_OF_T())

       Ts = typing.TypeVarTuple("Ts")
       P = typing.ParamSpec("P")

       def func(*args: *Ts, arg: Callable[P, T] = DEFAULT_OF_arg):
           ...

       func.__type_params__ = (T, Ts, P)
       return func
   func = decorator(TYPE_PARAMS_OF_func())

The capitalized names like "DEFAULT_OF_arg" are not actually bound at
runtime.


8.10.2. Generic classes
-----------------------

Generic classes are declared as follows:

   class Bag[T]: ...

This syntax is equivalent to:

   annotation-def TYPE_PARAMS_OF_Bag():
       T = typing.TypeVar("T")
       class Bag(typing.Generic[T]):
           __type_params__ = (T,)
           ...
       return Bag
   Bag = TYPE_PARAMS_OF_Bag()

Here again "annotation-def" (not a real keyword) indicates an
annotation scope, and the name "TYPE_PARAMS_OF_Bag" is not actually
bound at runtime.

Generic classes implicitly inherit from "typing.Generic". The base
classes and keyword arguments of generic classes are evaluated within
the type scope for the type parameters, and decorators are evaluated
outside that scope. This is illustrated by this example:

   @decorator
   class Bag(Base[T], arg=T): ...

This is equivalent to:

   annotation-def TYPE_PARAMS_OF_Bag():
       T = typing.TypeVar("T")
       class Bag(Base[T], typing.Generic[T], arg=T):
           __type_params__ = (T,)
           ...
       return Bag
   Bag = decorator(TYPE_PARAMS_OF_Bag())


8.10.3. Generic type aliases
----------------------------

The "type" statement can also be used to create a generic type alias:

   type ListOrSet[T] = list[T] | set[T]

Except for the lazy evaluation of the value, this is equivalent to:

   annotation-def TYPE_PARAMS_OF_ListOrSet():
       T = typing.TypeVar("T")

       annotation-def VALUE_OF_ListOrSet():
           return list[T] | set[T]
       # In reality, the value is lazily evaluated
       return typing.TypeAliasType("ListOrSet", VALUE_OF_ListOrSet(), type_params=(T,))
   ListOrSet = TYPE_PARAMS_OF_ListOrSet()

Here, "annotation-def" (not a real keyword) indicates an annotation
scope. The capitalized names like "TYPE_PARAMS_OF_ListOrSet" are not
actually bound at runtime.


8.11. Annotations
=================

Modifié dans la version 3.14: Annotations are now lazily evaluated by
default.

Variables and function parameters may carry *annotations*, created by
adding a colon after the name, followed by an expression:

   x: annotation = 1
   def f(param: annotation): ...

Functions may also carry a return annotation following an arrow:

   def f() -> annotation: ...

Annotations are conventionally used for *type hints*, but this is not
enforced by the language, and in general annotations may contain
arbitrary expressions. The presence of annotations does not change the
runtime semantics of the code, except if some mechanism is used that
introspects and uses the annotations (such as "dataclasses" or
"functools.singledispatch()").

By default, annotations are lazily evaluated in an annotation scope.
This means that they are not evaluated when the code containing the
annotation is evaluated. Instead, the interpreter saves information
that can be used to evaluate the annotation later if requested. The
"annotationlib" module provides tools for evaluating annotations.

If the future statement "from __future__ import annotations" is
present, all annotations are instead stored as strings:

   >>> from __future__ import annotations
   >>> def f(param: annotation): ...
   >>> f.__annotations__
   {'param': 'annotation'}

This future statement will be deprecated and removed in a future
version of Python, but not before Python 3.13 reaches its end of life
(see **PEP 749**). When it is used, introspection tools like
"annotationlib.get_annotations()" and "typing.get_type_hints()" are
less likely to be able to resolve annotations at runtime.

-[ Notes ]-

[1] L'exception est propagée à la pile d'appels à moins qu'il n'y ait
    une clause "finally" qui lève une autre exception, ce qui entraîne
    la perte de l'ancienne exception. Cette nouvelle exception
    entraîne la perte pure et simple de l'ancienne.

[2] Dans le filtrage par motif, une séquence est définie comme suit :

    * une classe qui hérite de "collections.abc.Sequence"

    * une classe Python qui a été enregistrée en tant que
      "collections.abc.Sequence"

    * une classe native dont le bit (CPython) "Py_TPFLAGS_SEQUENCE"
      est à 1

    * une classe qui hérite d'une classe citée ci-dessus

    Les classes suivantes de la bibliothèque standard sont des
    séquences :

    * "array.array"

    * "collections.deque"

    * "list"

    * "memoryview"

    * "range"

    * "tuple"

    Note:

      Les champs de recherche du type "str", "bytes" et "bytearray" ne
      correspondent pas avec des filtres de séquence.

[3] Dans le filtrage par motif, un tableau associatif est défini comme
    suit :

    * une classe qui hérite de "collections.abc.Mapping"

    * une classe Python qui a été enregistrée en tant que
      "collections.abc.Mapping"

    * une classe native dont le bit (CPython) "Py_TPFLAGS_MAPPING" est
      à 1

    * une classe qui hérite d'une classe citée ci-dessus

    Les classes  "dict" et "types.MappingProxyType" de la bibliothèque
    standard sont des tableaux associatifs.

[4] A string literal appearing as the first statement in the function
    body is transformed into the function's "__doc__" attribute and
    therefore the function's *docstring*.

[5] A string literal appearing as the first statement in the class
    body is transformed into the namespace's "__doc__" item and
    therefore the class's *docstring*.
