Programmer avec *asyncio*
*************************

La programmation asynchrone est différente de la programmation «
séquentielle » classique.

Cette page liste les pièges et erreurs communs que le développeur
pourrait rencontrer et décrit comment les éviter.


Mode débogage
=============

Par défaut, *asyncio* s'exécute en mode production. Pour faciliter le
développement, *asyncio* possède un « mode débogage ».

Il existe plusieurs façons d'activer le mode débogage de *asyncio* :

* en réglant la variable d’environnement "PYTHONASYNCIODEBUG" à "1" ;

* en utilisant le mode développement de Python (Python Development
  Mode) ;

* en passant "debug=True" à la fonction "asyncio.run()" ;

* en appelant la méthode "loop.set_debug()".

En plus d'activer le mode débogage, vous pouvez également :

* setting the log level of the asyncio logger to "logging.DEBUG", for
  example the following snippet of code can be run at startup of the
  application:

     logging.basicConfig(level=logging.DEBUG)

* configurer le module "warnings" afin d'afficher les avertissements
  de type "ResourceWarning" ; vous pouvez faire cela en utilisant
  l'option "-W" "default" sur la ligne de commande.

Lorsque le mode débogage est activé :

* beaucoup d'*API* *asyncio* ne prenant pas en charge les fils
  d'exécution multiples (comme les méthodes "loop.call_soon()" et
  "loop.call_at()") lèvent une exception si elles sont appelées par le
  mauvais fil d’exécution ;

* le temps d'exécution du sélecteur d'entrée-sortie est journalisé si
  une opération prend trop de temps à s'effectuer ;

* les fonctions de rappel prenant plus de 100 ms sont journalisées ;
  l'attribut "loop.slow_callback_duration" peut être utilisé pour
  changer la limite (en secondes) après laquelle une fonction de
  rappel est considérée comme « lente ».


Programmation concurrente et multi-fils
=======================================

Une boucle d'évènements s'exécute dans un fil d’exécution (typiquement
dans le fil principal) et traite toutes les fonctions de rappel
(*callbacks*) ainsi que toutes les tâches dans ce même fil. Lorsqu'une
tâche est en cours d'exécution dans la boucle d'évènements, aucune
autre tâche ne peut s'exécuter dans ce fil. Quand une tâche traite une
expression "await", elle se suspend et laisse la boucle d’évènements
traiter la tâche suivante.

Pour planifier un *rappel* depuis un autre fil d'exécution système,
utilisez la méthode "loop.call_soon_threadsafe()". Par exemple :

   loop.call_soon_threadsafe(callback, *args)

La plupart des objets *asyncio* ne sont pas conçus pour être exécutés
dans un contexte multi-fils (*thread-safe*) mais cela n'est en général
pas un problème à moins que l'objet ne fasse appel à du code se
trouvant en dehors d'une tâche ou d'une fonction de rappel. Dans ce
dernier cas, si le code appelle les *API* bas niveau de *asyncio*,
utilisez la méthode "loop.call_soon_threadsafe()". Par exemple :

   loop.call_soon_threadsafe(fut.cancel)

Pour planifier un objet concurrent depuis un autre fil d'exécution
système, utilisez "run_coroutine_threadsafe()". Cette fonction renvoie
un objet "concurrent.futures.Future" pour accéder au résultat :

   async def coro_func():
        return await asyncio.sleep(1, 42)

   # Later in another OS thread:

   future = asyncio.run_coroutine_threadsafe(coro_func(), loop)
   # Wait for the result:
   result = future.result()

To handle signals the event loop must be run in the main thread.

The "loop.run_in_executor()" method can be used with a
"concurrent.futures.ThreadPoolExecutor" or "InterpreterPoolExecutor"
to execute blocking code in a different OS thread without blocking the
OS thread that the event loop runs in.

Il n'y a actuellement aucune façon de planifier des coroutines ou des
rappels directement depuis un autre processus (comme, par exemple, un
processus démarré avec "multiprocessing"). La section Méthodes de la
boucle d'évènements liste les *API* pouvant lire les tubes (*pipes*)
et surveiller les descripteurs de fichiers sans bloquer la boucle
d'évènements. De plus, les *API* Subprocess d'*asyncio* fournissent un
moyen de démarrer un processus et de communiquer avec lui depuis la
boucle d'évènements. Enfin, la méthode "loop.run_in_executor()"
susmentionnée peut également être utilisée avec
"concurrent.futures.ProcessPoolExecutor" pour exécuter du code dans un
processus différent.


Exécution de code bloquant
==========================

Du code bloquant sur des opérations de calcul (*CPU-bound*) ne devrait
pas être appelé directement. Par exemple, si une fonction effectue des
calculs utilisant le CPU intensivement pendant une seconde, toutes les
tâches *asyncio* concurrentes et les opérations d'entrées-sorties
seront bloquées pour une seconde.

An executor can be used to run a task in a different thread, including
in a different interpreter, or even in a different process to avoid
blocking the OS thread with the event loop.  See the
"loop.run_in_executor()" method for more details.


Journalisation
==============

*Asyncio* utilise le module "logging". Toutes les opérations de
journalisation sont effectuées via l'enregistreur (*logger*)
""asyncio"".

The default log level is "logging.INFO", which can be easily adjusted:

   logging.getLogger("asyncio").setLevel(logging.WARNING)

La journalisation réseau peut bloquer la boucle d'événements. Il est
recommandé d'utiliser un fil d'exécution séparé pour gérer les
journaux ou d'utiliser des entrées-sorties non bloquantes. Par
exemple, voir Utilisation de gestionnaires bloquants.


Détection des coroutines jamais attendues
=========================================

Lorsqu'une fonction coroutine est appelée mais qu'elle n'est pas
attendue (p. ex.  "coro()" au lieu de "await coro()") ou si la
coroutine n'est pas planifiée avec "asyncio.create_task()", *asyncio*
émet un "RuntimeWarning" :

   import asyncio

   async def test():
       print("never scheduled")

   async def main():
       test()

   asyncio.run(main())

Sortie :

   test.py:7: RuntimeWarning: coroutine 'test' was never awaited
     test()

Affichage en mode débogage :

   test.py:7: RuntimeWarning: coroutine 'test' was never awaited
   Coroutine created at (most recent call last)
     File "../t.py", line 9, in <module>
       asyncio.run(main(), debug=True)

     < .. >

     File "../t.py", line 7, in main
       test()
     test()

La façon habituelle de régler ce problème est d'attendre (*await*) la
coroutine ou bien d'appeler la fonction "asyncio.create_task()" :

   async def main():
       await test()


Détection des exceptions jamais récupérées
==========================================

Si la méthode "Future.set_exception()" est appelée mais que l'objet
*Future* n'est pas attendu, l'exception n'est pas propagée au code
utilisateur. Dans ce cas, *asyncio* écrit un message dans le journal
lorsque l'objet *Future* est récupéré par le ramasse-miette.

Exemple d'une exception non-gérée :

   import asyncio

   async def bug():
       raise Exception("not consumed")

   async def main():
       asyncio.create_task(bug())

   asyncio.run(main())

Sortie :

   Task exception was never retrieved
   future: <Task finished coro=<bug() done, defined at test.py:3>
     exception=Exception('not consumed')>

   Traceback (most recent call last):
     File "test.py", line 4, in bug
       raise Exception("not consumed")
   Exception: not consumed

Activez le mode débogage pour récupérer la trace d'appels indiquant où
la tâche a été créée :

   asyncio.run(main(), debug=True)

Affichage en mode débogage :

   Task exception was never retrieved
   future: <Task finished coro=<bug() done, defined at test.py:3>
       exception=Exception('not consumed') created at asyncio/tasks.py:321>

   source_traceback: Object created at (most recent call last):
     File "../t.py", line 9, in <module>
       asyncio.run(main(), debug=True)

   < .. >

   Traceback (most recent call last):
     File "../t.py", line 4, in bug
       raise Exception("not consumed")
   Exception: not consumed


Asynchronous generators best practices
======================================

Writing correct and efficient asyncio code requires awareness of
certain pitfalls. This section outlines essential best practices that
can save you hours of debugging.


Close asynchronous generators explicitly
----------------------------------------

It is recommended to manually close the *asynchronous generator*. If a
generator exits early - for example, due to an exception raised in the
body of an "async for" loop - its asynchronous cleanup code may run in
an unexpected context. This can occur after the tasks it depends on
have completed, or during the event loop shutdown when the async-
generator's garbage collection hook is called.

To avoid this, explicitly close the generator by calling its
"aclose()" method, or use the "contextlib.aclosing()" context manager:

   import asyncio
   import contextlib

   async def gen():
     yield 1
     yield 2

   async def func():
     async with contextlib.aclosing(gen()) as g:
       async for x in g:
         break  # Don't iterate until the end

   asyncio.run(func())

As noted above, the cleanup code for these asynchronous generators is
deferred. The following example demonstrates that the finalization of
an asynchronous generator can occur in an unexpected order:

   import asyncio
   work_done = False

   async def cursor():
       try:
           yield 1
       finally:
           assert work_done

   async def rows():
       global work_done
       try:
           yield 2
       finally:
           await asyncio.sleep(0.1) # immitate some async work
           work_done = True


   async def main():
       async for c in cursor():
           async for r in rows():
               break
           break

   asyncio.run(main())

For this example, we get the following output:

   unhandled exception during asyncio.run() shutdown
   task: <Task finished name='Task-3' coro=<<async_generator_athrow without __name__>()> exception=AssertionError()>
   Traceback (most recent call last):
     File "example.py", line 6, in cursor
       yield 1
   asyncio.exceptions.CancelledError

   During handling of the above exception, another exception occurred:

   Traceback (most recent call last):
     File "example.py", line 8, in cursor
       assert work_done
              ^^^^^^^^^
   AssertionError

The "cursor()" asynchronous generator was finalized before the "rows"
generator - an unexpected behavior.

The example can be fixed by explicitly closing the "cursor" and "rows"
async-generators:

   async def main():
       async with contextlib.aclosing(cursor()) as cursor_gen:
           async for c in cursor_gen:
               async with contextlib.aclosing(rows()) as rows_gen:
                   async for r in rows_gen:
                       break
               break


Create asynchronous generators only when the event loop is running
------------------------------------------------------------------

It is recommended to create *asynchronous generators* only after the
event loop has been created.

To ensure that asynchronous generators close reliably, the event loop
uses the "sys.set_asyncgen_hooks()" function to register callback
functions. These callbacks update the list of running asynchronous
generators to keep it in a consistent state.

When the "loop.shutdown_asyncgens()" function is called, the running
generators are stopped gracefully and the list is cleared.

The asynchronous generator invokes the corresponding system hook
during its first iteration. At the same time, the generator records
that the hook has been called and does not call it again.

Therefore, if iteration begins before the event loop is created, the
event loop will not be able to add the generator to its list of active
generators because the hooks are set after the generator attempts to
call them. Consequently, the event loop will not be able to terminate
the generator if necessary.

Consider the following example:

   import asyncio

   async def agenfn():
       try:
           yield 10
       finally:
           await asyncio.sleep(0)


   with asyncio.Runner() as runner:
       agen = agenfn()
       print(runner.run(anext(agen)))
       del agen

Sortie :

   10
   Exception ignored while closing generator <async_generator object agenfn at 0x000002F71CD10D70>:
   Traceback (most recent call last):
     File "example.py", line 13, in <module>
       del agen
           ^^^^
   RuntimeError: async generator ignored GeneratorExit

This example can be fixed as follows:

   import asyncio

   async def agenfn():
       try:
           yield 10
       finally:
           await asyncio.sleep(0)

   async def main():
       agen = agenfn()
       print(await anext(agen))
       del agen

   asyncio.run(main())


Avoid concurrent iteration and closure of the same generator
------------------------------------------------------------

Async generators may be reentered while another "__anext__()" /
"athrow()" / "aclose()" call is in progress. This may lead to an
inconsistent state of the async generator and can cause errors.

Let's consider the following example:

   import asyncio

   async def consumer():
       for idx in range(100):
           await asyncio.sleep(0)
           message = yield idx
           print('received', message)

   async def amain():
       agenerator = consumer()
       await agenerator.asend(None)

       fa = asyncio.create_task(agenerator.asend('A'))
       fb = asyncio.create_task(agenerator.asend('B'))
       await fa
       await fb

   asyncio.run(amain())

Sortie :

   received A
   Traceback (most recent call last):
     File "test.py", line 38, in <module>
       asyncio.run(amain())
       ~~~~~~~~~~~^^^^^^^^^
     File "Lib/asyncio/runners.py", line 204, in run
       return runner.run(main)
              ~~~~~~~~~~^^^^^^
     File "Lib/asyncio/runners.py", line 127, in run
       return self._loop.run_until_complete(task)
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
     File "Lib/asyncio/base_events.py", line 719, in run_until_complete
       return future.result()
              ~~~~~~~~~~~~~^^
     File "test.py", line 36, in amain
       await fb
   RuntimeError: anext(): asynchronous generator is already running

Therefore, it is recommended to avoid using asynchronous generators in
parallel tasks or across multiple event loops.
