Python 3.5 : enfin comprendre le fonctionnement d'un code asynchrone

Pour en revenir à notre problème d'avoir plusieurs tâches à gérer en même temps, nous avons aujourd'hui et historiquement, deux grandes familles qui « s'affrontent » - disposant chacune de grandes forces et faiblesses :

• les threads : du calculconcurrentiel (car sur un seul processus) qui, en résumé, « subdivise » le temps disponible de calcul du processeur pour un programme, en une multitude d'autres temps pour des calculs en interne du programme. La mémoire et le temps de calcul sont « partagés ». Les threads sont faciles conceptuellement, mais offrent certaines limites : ils n'utilisent qu'un seul cœur de processeur qui est donc surutilisé (la pratique est parfois différente suivant les architectures) et il est nécessaire de consommer beaucoup de ressources pour gérer les threads - avec une limite (GIL) évoquée plus loin. La gestion des ressources est parfois délicate (par exemple, une base SQLitle), car chaque thread ne s'occupe pas de ses frères et il est nécessaire d'utiliser des « verrous » (locks) pour éviter des accès simultanés et mortifères.
  Les threads disposent d'un module dédié et natif dans la bibliothèque standard de Python.
• les multiprocess : du calcul parallèle (car sur plusieurs processus) qui utilisent utilement les nombreux cœurs dont disposent désormais nos processeurs. Le principe est de déléguer à un nouveau processus Python (multiprocessing, fork) ou à un appel système différent (subprocess), une part du travail de manière indépendante en termes de calcul, du processus parent. Cependant la mise en œuvre est complexe : il faut les faire dialoguer entre eux, et le code, parfois pour quelques lignes de calculs, peut alors devenir indigeste. La séparation des processus ne résout pas nécessairement les problèmes de concurrence lors de l'accès aux ressources : les verrous restent nécessaires… de plus il n'y a pas des variables communes : il est nécessaire d'avoir un niveau d'abstraction supplémentaire pour faire dialoguer en temps réel, le partage d'une variable ou de son édition.

Finalement dans tout cela, ce que l'on veut tous faire, tout le temps, c'est dire à la machine : plutôt qu'attendre, fais autre chose. Puis reviens reprendre ton travail lorsqu'on t'en donne le signal ou qu'une ressource est disponible.

Face à ce défi et à l'évolution (positive) des pratiques, une nouvelle organisation de l'écriture séquentielle a vu le jour : offrir la souplesse des threads sans le problème de chaos et certaines limitations natives ; ou partir sur une nouvelle manière de créer un autre processus - donc en restant restreint à un seul cœur de processeur… Cette évolution c'est l'asynchrone ou quand le séquentiel ne se comporte plus tout à fait comme il l'a toujours fait jusqu'à présent. Mais le mode asynchrone n'est ni un « nouveau » thread, ni un nouveau processus dans le programme. C'est autre chose, qui n'est pas une troisième voie, mais une autre voie.

La nouveauté offerte par le mode asynchrone et sa puissance réelle par certains aspects, a fait naître la « mode » de l'asynchronisme à tous les étages, le don de faire une multitude de choses « en parallèle »… et son cortège d'illusions : il n'y a en réalité qu'une seule et unique tâche à un instant t. C'est bien la vitesse qui simule le parallélisme.

Cette mode, parfois déraisonnable, est notamment portée grâce au web par JavaScript type Node.JS ou le logiciel nginx, qui pulvérisent effectivement tous deux les performances d'Apache et son approche très classique…

Pour une partie de la communauté des développeurs, l'asynchronisme c'est devenu, c'était donc (et c'est encore) un truc dédié pour le web, pour le réseau ou pour l'accès à l'interface E/S des fichiers ; pas pour le calcul pur ou une conception plus « classique » du logiciel. Sans être faux, ce raisonnement est limité, car c'est en réalité une conception différente de l'utilisation du temps processeur, des accès fichiers et des ressources RAM… Faisons le point sur les mérites et les failles avec méthode et objectivité.

Je vais doucher vos espoirs tout de suite : votre serveur saupoudré d'asynchronisme ne sera pas plus performant dans l'absolu, vous passerez juste moins de temps à attendre (et donc vous en profitez pour en faire plus, mais sans dépasser la possibilité totale native de calcul du système). La démonstration de ce qu'est et n'est pas l'asynchronisme est l'objet de ce tutoriel, en plus de vous le faire découvrir.

Vous y gagnerez une forme de parallélisme des tâches certes. Ce parallélisme permet de répondre à davantage de sollicitations, mais le cœur même du calcul de votre script - au travers de vos fonctions - restera présent et n'en sera pas modifié. Et le temps de réponse d'une ressource aussi. Par exemple : votre requête mal ficelée en MySQL qui prend trois secondes à s'exécuter avant de vous retourner le résultat, multiplié par des milliers d'utilisateurs en simultané, ne s'arrangera pas. La requête fera toujours trois secondes et s'il n'y a pas d'autres tâches à réaliser en attendant (cas d'école !), votre script tournera tout autant dans le vide qu'avant.

Pire, sur le calcul pur, les threads sont plus simples et plus performants ; moins que ce peut être le multiprocessing sur un processeur multicœur, qui explosera l'efficacité de l'asynchronisme sans l'ombre d'un doute. À chaque usage les performances de ces solutions varient.

Avant de revenir à ces conclusions, il vous faudra un long, très long parcours aux confins du langage si délicieux de Python… Même si vous n'êtes pas un habile programmeur, c'est à la portée de tous. Encore faut-il bien en comprendre les ressorts pour ne pas en perdre le sel...

Le mot-clé yield n'est pas une particularité de Python : on le retrouve historiquement dans le C ou dans JavaScript, comme l'illustre l'article associé sur MDN. Malgré sa notoriété finalement assez faible - peu de tutoriels l'évoquent lors de l'initiation à la programmation -, sa puissance le rend incontournable lors d'une programmation poussée et professionnelle.

C'est un mot-clé un peu particulier, qui se rapproche de with ou encore l'opérateur @ pour les décorateurs : il est une sorte de « raccourci » qui renferme la complexité et retourne un objet qui est différent de celui-ci initialement fourni (fonction X → objet G). yield a une particularité : il ne fonctionne QUE dans les fonctions (ou les fonctions des objets, que l'on appelle communément les méthodes, avec lesquelles il travaille sans problème). Il retourne systématiquement un objet (une classe instanciée) de type « generator » (générateur). L'asynchronisme appelle ce générateur différemment, nous y reviendrons en fin de cet article ; son nom véritable n'a que peu d'importance pour l'instant.

Jusque-là c'est facile ? Oui mais, il y a une nuance… un générateur se comporte avant tout comme un « itérateur » que l'on retrouve partout dans Python ! Rappelons tout d'abord ce qu'est un itérable : il s'agit d'un objet qui garde en mémoire d'une manière finie (range(0,9), par exemple) ou infinie (le retour d'un calcul dans une boucle while True), une série d'autres objets/une valeur lorsqu'on l'itère (l'itérable a donc besoin d'être itéré par un itérateur, un iterator). De nombreux exemples des itérables et de leur intérêt sont déjà fournis sur le site (voir à ce sujet l'article d'Alexandre Galode pour les propriétés). Un itérateur renvoie donc une valeur à chaque passage/appel et il permet de contrôler ces passages de manière fine.

Un generator est un itérable (en somme il se parcourt lui-même) - et l'inverse, pour les itérateurs, n'est pas loin d'être vrai : un itérateur est, dans le code Python, à rapprocher d'un generator par certaines méthodes - même si leur ressemblance s'arrête là. Cependant et comme nous le verrons plus loin, les concepts d'itération, de machines à états, d'asynchronisme ou de call-back, forment une masse où il est parfois difficile de définir des cas d'utilisation tout à fait clairs. Pour respecter les règles de l'écriture « pythonique » et les orientations de chaque sensibilité du développement, la communauté a ainsi créé de nouveaux mots-clés (dont yield from et async/await) qui tentent d'éclaircir l'orientation du développement. Reste derrière cela, qu'il s'agit toujours d'un fonctionnement similaire (découper en portion individuelle « à la volée ») avec des subtilités qu'il faut connaître.

Dans le détail, les « iterators type » sont des objets (des containers, des boîtes en somme), qui permettent de renvoyer une valeur unique à chaque appel (grâce à la méthode __next__₎. Lors de la création (par exemple, lors d'un appel dans une boucle for), c'est le même nom __iter__ qui est utilisé pour renvoyer l'itérateur depuis la classe de départ, puis une valeur. Pour yield, la méthode __iter__ n'est disponible que lorsque la fonction de départ a été appelée une première fois ; sinon elle est référencée et se comporte comme une fonction normale. Il y a donc une « transformation » de l'appel de la fonction en autre chose (voir plus haut la transformation fonction X → objet G).

Les fonctions __iter__ et __next__ sont ensuite disponibles pour les generators. Nous pourrons donc utiliser dans nos boucles for des générateurs ou des itérateurs indifféremment. Pratique !

En voici la démonstration :

>>> range(0,1)
range(0, 1)
>>> type(range(0,1))
<class 'range'>
>>> range(0,1).__iter__
<method-wrapper '__iter__' of range object at 0xb676b2c0>
>>> range.__iter__
<slot wrapper '__iter__' of 'range' objects>

>>> def test():
    yield
>>> type(test())
<class 'generator'>
>>> test().__iter__ # on demande __iter__ sur une fonction appelé 
<method-wrapper '__iter__' of generator object at 0xb5b4220c>
>>> test.__iter__ # on demande __iter__ sur une variable contenant la fonction  non-appelée 
Traceback (most recent call last):
  File "<pyshell#10>", line 1, in <module>
    test.__iter__
AttributeError: 'function' object has no attribute '__iter__'
>>> test().__next__
<method-wrapper '__next__' of generator object at 0xb5b42a4c>

Un itérateur peut donc être « caché » dans une fonction appelée - en quelque sorte « encapsulé » dans un container, avant d'être disponible. Et l'itérable est le generator ; les deux étant liés grâce, par exemple, à un décorateur (comme vous pouvez le lire un peu partout avec @asyncio.coroutine).

Normal c'est l'enjeu même du tutoriel et nous n'en sommes qu'au début. Ce qu'il faut comprendre, et retenir, c'est la philosophie Python : tout est objet et ainsi, pour avoir des comportements les plus génériques possible, on utilise des méthodes d'objets avec des noms similaires pour un même contexte. Peu importe votre point de départ, c'est l'objet qui est généré à l'arrivée et rendu qui comptera : c'est ainsi que cela fonctionne dans Python, où par exemple la fonction (définie par défaut) iter() prend un itérable en entrée et lui « ajoute » le générateur synchrone nécessaire pour le parcourir facilement.

Il s'agit, dans notre cas, du protocol iterator - du protocole d'itération -, la manière dont Python fera appel à des objets grâce à des méthodes aux noms génériques.

Tentons pour rendre cela plus concret, de simuler une boucle for qui affichera les lettres contenues dans une liste (une liste = un itérable).

Voici le comportement normal et attendu :

>>> type(["a","b","c"])
<class 'list'>
>>> ["a","b","c"].__iter__
<method-wrapper '__iter__' of list object at 0xb5b4e42c>
>>> for lettre in ["a","b","c"]:
    print("-", lettre)
- a
- b
- c

Voici comment nous pourrions faire pour éviter d'utiliser totalement les listes en reproduisant le même résultat, en gardant à l'esprit que j'ai ajouté des commentaires :

class MonPremierIterable():
 
    def __init__(self, v1, v2, v3):
        print("itérable : on fait appel à bibi ?") 
        self.v1, self.v2, self.v3 = v1, v2, v3 
        self.i = 1
 
    def __next__(self):
        print("itérable : j'en suis à :", self.i) 
        if self.i==1:
            self.i += 1 
            return self.v1
        elif self.i==2:
            self.i += 1 
            return self.v2
        elif self.i==3:
            self.i += 1 
            return self.v3
        else: 
            print("itérable : j'ai fini") 
            raise StopIteration("je retourne la valeur que je veux, nah") 
 
 
class MaPremiereListe:
 
    def __init__(self, v1, v2, v3):
        print("simili-liste : je débute ma création") 
        self.v1, self.v2, self.v3 = v1, v2, v3 
 
    def __iter__(self):
        print("simili-list : __iter__ est appelé")
        return MonPremierIterable(
            self.v1,
            self.v2,
            self.v3
        ) 
 
for lettre in MaPremiereListe("a","b","c"):
    print("-", lettre)

… donnera :

simili-liste : je débute ma création
simili-list : __iter__ est appelé
itérable : on fait appel à bibi ?
itérable : j'en suis à : 1
- a
itérable : j'en suis à : 2
- b
itérable : j'en suis à : 3
- c
itérable : j'en suis à : 4
itérable : j'ai fini

En résumé :
- un itérable est un objet qui a des propriétés pour garder des éléments/des valeurs. Il peut « produire » un iterator sans que cela soit impératif (tout dépend du contexte, dont une partie est définie par le protocole standard associé) ;
- un iterator est un itérable avec la méthode __next__ qui lui permet de parcourir des éléments/des valeurs (ce parcours est choisi arbitrairement : filtre, tri, pas, etc.) ;
- le protocole d'itération donnera pour consigne de lever une exception (le mot-clé raise ) de type StopIteration (donc une exception d'un type particulier) qui dispose pour paramètre d'une seule valeur telle que pourrait le faire return . La boucle for n'affichera pas l'erreur, mais la gérera et ne fera rien (pour l'instant) de la valeur de l'exception - nous verrons bientôt son intérêt…

Un générateur produit par un fonction qui contient yield, va parcourir chaque portion de code du début jusqu'au prochain yield (ou de yield en yield ), tel que peut le faire un iterator . En somme, c'est un iterator qui utilise du code Python comme itérable…

Pour reprendre l'exemple de ma liste au-dessus, l'utilisation d'un générateur donnerait le code suivant :

def generateur(v1, v2, v3):
    yield v1
    yield v2
    yield v3
 
class MaPremiereListe:
 
    def __init__(self, v1, v2, v3):
        print("simili-liste : je débute ma création") 
        self.v1, self.v2, self.v3 = v1, v2, v3
 
    def __iter__(self):
        return generateur(self.v1, self.v2, self.v3) 
 
for lettre in MaPremiereListe("a","b","c"):
    print("-", lettre)

En plus court :

def MaPremiereListe(v1, v2, v3):
    yield v1
    yield v2
    yield v3
 
for lettre in MaPremiereListe("a","b","c"):
    print("-", lettre)

Pour illustrer qu'il n'y a bien qu'une portion de code exécutée, mettons un grain de sable :

GrainDeSable = 0 
 
def MaPremiereListe(v1, v2, v3):
    global GrainDeSable 
    print("je fais quelque chose ...")
    GrainDeSable +=1 
    yield v1
    print("... j'continue, toussa toussa ...")
    yield v2
    print("allez j'me lance :", GrainDeSable)
    print("et j'arrête avant la fin en provoquant une erreur \
qui ne soit pas une StopIteration") 
    raise Exception("on arrête")
    yield v3
 
for lettre in MaPremiereListe("a","b","c"):
    print("-", lettre)

… donnera :

je fais quelque chose ...
- a
... j'continue, toussa toussa ...
- b
allez j'me lance : 1
et j'arrête avant la fin en provoquant une erreur qui ne soit pas une StopIteration
Traceback (most recent call last):
  File "/home/julien/Bureau/tuto async/ref-5.py", line 16, in <module>
    for lettre in MaPremiereListe("a","b","c"):
  File "/home/julien/Bureau/tuto async/ref-5.py", line 13, in MaPremiereListe
    raise Exception("on arrête")
Exception: on arrête

Vous devinez la suite : on détournera la fonction d'itération afin de disposer d'une sorte de «  fonction en mode pause  » à la demande où la méthode __next__ du generator permet de reprendre temporairement la poursuite jusqu'au prochain yield ou en levant une exception StopIteration si la fonction se termine. Et le paramètre unique de StopIteration est… la valeur de retour de cette fonction.

Cette gestion try/except permet de renvoyer des valeurs None ( null ) sans problème particulier et d'en gérer plus finement l'usage, notamment en permettant au code qui gère le generator de détecter comment et quand se termine la fonction : normalement avec un StopIteration ou anormalement avec toutes les autres formes d'exception.

Par convention :
- on préférera toujours utiliser une boucle while True associée à next() , pour ne pas se poser la question du nombre d'itérations : l'itérable peut être infini et la boucle s'arrête par le déclenchement d'une exception de StopIteration  ;
- on utilisera la fonction native next() qu'appelle la méthode __next__ du générateur. Ainsi next(g) et g.__next__() sont strictement équivalents.

def MaFonction(valeur):
    i = 2 
    valeur = int(valeur) 
    i  = valeur
    yield
    i  = (valeur valeur)
    return i 
 
try:
    generateur = MaFonction(3) 
    while True:
        next(generateur)
except StopIteration as retour:
    print(retour.value) # soit (2 x 3) x (3 x 3) ou 54

Parfois on a des générateurs dans les générateurs… Il faut alors gérer la question des exceptions StopIteration à tous les niveaux - c'est pénible et hasardeux, car si l'on en oublie un, telle une bulle, l'exception StopIteration levée et non interceptée, remontera au générateur au-dessus qui s'arrêtera - ce qui n'est pas du tout le comportement attendu.

Pour cela, Python a aussi une solution simplifiant l'écriture et évitant les erreurs de logique programmatique : yield from. C'est la même chose qu'un yield, mais en prenant une autre fonction qui retourne un générateur.

Voyons ce que ça donne pour afficher l'alphabet :

def LettreGI():
    print("g") 
    yield 
    print("h") 
    yield 
    print("i")
    return "coucou" 
 
def LettreDI():
    print("d") 
    yield 
    print("e") 
    yield 
    print("f")
    r = yield from LettreGI()
    return r 
 
def LettreAC():
    print("a") 
    yield 
    print("b") 
    yield 
    print("c") 
 
def Afficher():
    r = yield from LettreAC()
    print("! r = ", r) 
    r = yield from LettreDI() 
    print("! r = ", r)
    return "bonjour" 
 
try:
    generateur = Afficher() 
    while True:
        next(generateur)
except StopIteration as retour:
    print(retour.value)

… donnera : 

a
b
c
! r =  None
d
e
f
g
h
i
! r =  coucou
bonjour

Les lecteurs attentifs auront peut-être déjà remarqué que yield , comme yield from , pouvait prendre ou non une valeur comme « paramètre » (valeur située à droite) et en retourner une (valeur située à gauche). C'est optionnel et c'est la puissance des generators  : permettre non seulement de mettre une fonction en pause, mais en plus pouvoir communiquer avec elle au moment de la pause (en entrée et en sortie de pause).

Mieux : le yield from permet d'être « transparent » et de donner complètement la main au générateur contenu dans un autre générateur.

Sur l'exemple de mon alphabet précédemment, je pourrais donc écrire :

def Afficher():
    while True:
        lettre = yield
        if lettre is None:
            return "bonjour"
        else:
            print(lettre) 
 
try:
    alphabet = ["a","b","c","d","e","f","g","h","i"] 
    generateur = Afficher() 
    for lettre in alphabet: 
        generateur.send(lettre) 
except StopIteration as retour:
    print(retour.value)

Et là paf, une erreur :

Traceback (most recent call last):
  File "/home/julien/Bureau/tuto async/ref-8.py", line 38, in <module>
    generateur.send(lettre)
TypeError: can't send non-None value to a just-started generator

Impossible d'envoyer une valeur ! Pourquoi ? Parce que yield fonctionne « de droite à gauche », c'est-à-dire qu'il met d'abord en pause la fonction sous forme de générateur puis envoie une donnée éventuellement fournie (ou None en son absence) avant d'en recevoir une (ou None en son absence). Lui demander de transmettre une donnée avant même une première mise en pause n'est pas admis et ne peut pas l'être, car aucun yield n'a été encore rencontré et donc aucune portion de code n'a été exécutée.

Le code correct est donc :

def Afficher():
    premiere_fois = True 
    while True:
        lettre = yield ("je démarre" if premiere_fois else None) 
        if lettre is None:
            return "bonjour"
        else:
            print(lettre)
        premiere_fois = False 
 
try:
    alphabet = ["a","b","c","d","e","f","g","h","i"] 
    generateur = Afficher()
    print(next(generateur))
    for lettre in alphabet: 
        generateur.send(lettre) 
except StopIteration as retour:
    print(retour.value)

Et là vous me direz : moi je veux recevoir et envoyer. C'est possible ? Testons ! Changeons une portion du code :

try:
    alphabet = ["a","b","c","d","e","f","g","h","i"] 
    generateur = Afficher()
    for lettre in alphabet: 
        print(next(generateur))
except StopIteration as retour:
    print(retour.value)

… donnera : 

je démarre
bonjour

Tiens, le « bonjour » revient alors qu'il avait disparu : logique, comme je n'envoie pas None dans mon try / except , le générateur n'est jamais arrêté et donc l'exception n'est pas levée… Cette erreur, discrète et volontaire dans ce tutoriel, illustre la difficulté parfois à trouver les coquilles des scripts : l'asynchronisme ne se débogue pas aussi simplement que le séquentiel/synchrone.

try:
    alphabet = ["a","b","c","d","e","f","g","h","i"] 
    generateur = Afficher()
    for lettre in alphabet: 
        print(next(generateur))
except StopIteration as retour:
    print(retour.value) 
finally:
    print("fin")

Donnera 

je démarre
bonjour
fin

Logique ! Nous devons donc respecter les étapes d'appel et, dans notre cas, d'arrêt de la boucle while True dans Afficher(), pour réaliser totalement le script :

def Afficher():
    premiere_fois = True 
    while True:
        lettre = yield ("je démarre" if premiere_fois else "je continue") 
        if lettre is None:
            return "bonjour"
        else:
            print(lettre)
        premiere_fois = False 
 
try:
    alphabet = ["a","b","c","d","e","f","g","h","i"] 
    generateur = Afficher()
    print(next(generateur)) 
    for lettre in alphabet: 
        print(generateur.send(lettre))
    generateur.send(None)
except StopIteration as retour:
    print(retour.value) 
finally:
    print("fin")

… donnera :

je démarre
a
je continue
b
je continue
c
je continue
d
je continue
e
je continue
f
je continue
g
je continue
h
je continue
i
je continue
bonjour
fin

Avec un yield from , pas de changement de comportement :

def Afficher():
    premiere_fois = True 
    while True:
        lettre = yield ("je démarre" if premiere_fois else "je continue") 
        if lettre is None:
            return "bonjour"
        else:
            print(lettre)
        premiere_fois = False 
 
def proxy():
    r = yield from Afficher()
    return r 
 
try:
    alphabet = ["a","b","c","d","e","f","g","h","i"] 
    generateur = proxy()
    print(next(generateur)) 
    for lettre in alphabet: 
        print(generateur.send(lettre))
    generateur.send(None)
except StopIteration as retour:
    print(retour.value) 
finally:
    print("fin")

… donnera (toujours) ;

je démarre
a
je continue
b
je continue
c
je continue
d
je continue
e
je continue
f
je continue
g
je continue
h
je continue
i
je continue
bonjour
fin

Vous vous disiez que le plus dur était passé ? Eh bien, non ! Heureusement pour vous, on ne change rien dans les mots-clés et les concepts : nous poussons le raisonnement un peu plus loin.

Tout d'abord en intégrant une dimension temporelle à nos tâches. Pour l'instant, c'est l'ordre d'arrivée qui compte et la plus ancienne (c'est-à-dire celle qui part de 0 dans la liste d'attente) qui est traitée en premier. Sans autre possibilité de la différer dans le temps. Attention, il ne s'agit pas de la conditionner à un état ou à une autre fonction, juste… d'attendre.

Et attendre c'est facile avec yield  : il suffit d'avoir une boucle qui compare deux valeurs de temps. Si la valeur est négative, il faut encore attendre. Si c'est positif, on peut continuer. À chaque itération, on teste cette simple condition. Vous savez ce qu'est une liste de tâches ordonnée dans le temps ? Un agenda. Alors appelons notre variable « temps » comme cela !

Si l'on attend, il faudra aussi avoir un moyen d'annuler cette tâche qui sera réalisée à l'instant voulu. Notre ajout d'une tâche va donc devoir générer un numéro unique (ici un simple compteur incrémentiel).

class Gestionnaire:
 
    __numero__ = -1 # pour que la première tâche soit à 0  
    taches = [] 
 
    def __init__(self):
        pass
 
    @property
    def numero(self):
        self.__numero__ += 1 
        return self.__numero__
 
    def tache(self, numero, duree, fct,   args):
        numero = self.numero if numero is None else numero # faire appel à cette propriété simulée "self.numero" (qui en réalité une méthode de l'objet, nous donne la possibilité de faire automatiquement l'incrémentation : il n'y aura donc jamais de doublon 
        agenda = [(duree if isinstance(duree, int) else 0), 0] 
        self.taches.append((
            numero, 
            agenda, 
            fct, 
            args
        ))
        return numero 
 
    def lancer(self):
        demarrage = time.time() 
        while len(self.taches)>0:
            numero, agenda, fct, args = self.taches.pop(0)
            if isinstance(fct, types.GeneratorType):
                try:
                    next(
                        fct 
                    )
                    self.tache(
                        numero,
                        agenda[1], 
                        fct,
                        args
                    ) 
                except StopIteration: 
                    pass 
            elif callable(fct):
                try:
                    duree, debut = agenda
                    if debut==0:
                        debut = time.time()
                    self.tache(
                        numero,
                        [duree, debut], 
                        fct( args) if (debut-demarrage)>=duree else fct, # on exécute... ou pas
                        args
                    ) 
                except Exception as err:
                    print(fct, err)

Testons maintenant avec des fonctions retardées et trèèèès lentes… au passage et avant de les lancer dans votre console, devinez combien de temps va durer au total ce script ? Au moins six secondes, car fct2() fera appel à fct1() qui va durer au moins quatre secondes, auxquelles s'ajoute deux secondes supplémentaires. Comme fct1() appelée directement, s'exécute « en parallèle », sa durée ne s'ajoute pas et son retardement d'une seconde ne change rien.

def attendre(duree):
    depart = time.time() 
    while (time.time()-depart)<duree: 
        yield 
 
def fct1(appel_par):
    print("fct1 : j'ai commencé ; appelée par", appel_par) 
    yield from attendre(1) # attente d'1 seconde
    print("fct1 : j'en suis au milieu ; appelée par", appel_par) 
    yield from attendre(3) # attente de 3 seconde 
    print("fct1 : j'ai fini ; appelée par", appel_par)
 
def fct2():
    print("fct2 : j'ai commencé") 
    yield from fct1("fct2")
    print("fct2 : j'en suis au milieu") 
    yield from attendre(2)
    print("fct2 : j'ai fini")
 
def fct3():
    print("je n'attends rien et je ne suis même pas un générateur") 
 
debut = time.time()
gestionnaire = Gestionnaire() 
gestionnaire.tache(
    None, # on laisse le script assigné le bon numéro
    1, # on retarde d'une seconde 
    fct1,
    "personne !" 
) 
gestionnaire.tache(
    None, 
    0, # on exécute dès que possible
    fct2 
)
gestionnaire.tache(
    None, 
    0, 
    fct3 
)
gestionnaire.lancer() 
fin = time.time() 
print(fin-debut, "secondes")

… donnera (lentement) …

fct3 : je n'attends rien et je ne suis même pas un générateur
fct2 : j'ai commencé
fct1 : j'ai commencé ; appelée par fct2
fct1 : j'ai commencé ; appelée par personne !
fct1 : j'en suis au milieu ; appelée par fct2
fct1 : j'en suis au milieu ; appelée par personne !
fct1 : j'ai fini ; appelée par fct2
fct2 : j'en suis au milieu
fct1 : j'ai fini ; appelée par personne !
fct2 : j'ai fini
6.21833872795105 secondes

Sans l'asynchronisme, nous aurions dû attendre un peu plus de 11 secondes , soit l'addition de l'ensemble des temps d'attente de toutes les fonctions. Notre script paraît donc « deux fois plus rapide » (nous verrons dans le chapitre suivant que ce n'est pas tout à fait vrai).

Voilà à la dernière étape de la complexification. Humainement, nous sommes aux limites de la pensée complexe, car à partir de maintenant, la prédictibilité « naturelle » et le nombre d'états possibles pour notre gestionnaire de tâches (qui n'a pourtant pas pris une ampleur démesurée !) dépasseront ce qu'il est possible de coucher sur le papier.

En d'autres termes, l'asynchronisme devient une boîte noire, une forme de théorie de ce que l'on souhaite faire et qu'il est difficile de visualiser dans son ensemble et dans le temps. Seules la pratique et l'expérience de son propre code renseignent. Même quelques lignes de codes peuvent devenir un enfer en cas de pépin ! Son utilisation, même si elle est parfois tentante, doit être raisonnable.

La « promesse » que l'on rajoute, c'est un principe de call-back (fonctions de rappel en bon français) et d'états non encore définis. C'est-à-dire que nous aurons des fonctions ordonnées dans chaque tâche (en gros l'organisation interne de la tâche) avec la possibilité pour ces mêmes tâches, individuellement, d'avoir accès à des états qui ne peuvent pas être connus au moment où elles sont appelées. Le tout forme un objet « promesse » qui est étendu naturellement par les fonctions de rappel, qui ont pour paramètre ce même objet.

Impossible de traiter des données non encore définies ? Presque : un générateur est après tout une promesse d'un traitement, que l'on appelle au moment où on le souhaite. Les notions sont similaires et offrent une grande liberté dans la pratique.

Dans notre cas, la promesse d'un traitement se lie à l'affectation d'un résultat : ma promesse enregistre des fonctions à appeler lorsque le résultat est connu et, dans l'attente, se retourne elle-même pour être « transportée » ailleurs si nécessaire. On échange donc pas une valeur à proprement parler, mais une sorte de signature, d'enregistrement, de ce quelle sera. Là encore, c'est le passage par référence et non par valeur (on stocke la référence d'une valeur et non la valeur elle-même), qui permet un tel résultat.

Dès que la promesse est réalisée, c'est-à-dire qu'on lui assigne son état final, on déclenche alors chacune des fonctions qui lui est associée et toutes les variables qui lui sont attachées, peuvent disposer du résultat de la promesse.

Dès lors on peut imaginer que la tâche est elle-même une promesse et que le gestionnaire de tâches n'est finalement qu'un ordonnateur non pas de tâches, mais de promesses qui seront réalisées. Ce sont aux promesses d'organiser les tâches au travers du gestionnaire.

Testons et tout d'abord modifions notre gestionnaire. Il prendra désormais de manière optionnelle un numéro, une durée d'attente et une fonction de rappel. Cette fonction de rappel sera réalisée après la réalisation de la fonction initiale de tâche et, l'une comme l'autre, peuvent être ou non des générateurs.

import types
import time 
 
class Gestionnaire:
 
    __numero__ = -1 # pour que la première tâche soit à 0  
    taches = [] 
 
    def __init__(self):
        pass
 
    @property
    def numero(self):
        self.__numero__ += 1 
        return self.__numero__
 
    def tache(self, fct,  args, numero=None, duree=0, rappel=None): 
        numero = self.numero if numero is None else numero 
        agenda = [(duree if isinstance(duree, int) else 0), 0] 
        self.taches.append((
            numero, 
            agenda,
            rappel, 
            fct, 
            args
        ))
        return numero 
 
    def lancer(self):
        demarrage = time.time() 
        while len(self.taches)>0:
            poursuite = False 
            numero, agenda, rappel, fct, args = self.taches.pop(0) 
            if isinstance(fct, types.GeneratorType):
                try:
                    next(
                        fct 
                    )
                    poursuite = True 
                except StopIteration: 
                    if callable(rappel):
                        fct = rappel 
                        rappel = None 
                        args = () 
                        poursuite = True 
                except Exception as err:
                    print("! err : ", fct, err)
            elif callable(fct):
                try:
                    duree, debut = agenda
                    if debut==0:
                        debut = time.time()
                    if (debut-demarrage)>=duree: 
                        fct = fct( args) 
                    poursuite = True
                except Exception as err:
                    print("! err : ", fct, err)
            elif callable(rappel): 
                fct = rappel
                rappel = None 
                args = () 
                poursuite = True 
            if poursuite: 
                self.taches.append(( 
                    numero, 
                    [duree, debut],
                    rappel, 
                    fct,  
                    args
                ))

Pour la classe Promesse, c'est facile : on déclare un gestionnaire, une possibilité d'ajouter des fonctions de rappel pour la promesse et on affecte une valeur comme résultat de celle-ci. Cette « réalisation » enclenche une méthode qui insère, comme un itérable, les fonctions de rappels les unes après les autres au sein du gestionnaire, en prenant en rappel de tâche la méthode __realisation__ de la promesse elle-même.

class Promesse:
 
    gestionnaire = None 
 
    def __init__(self, gestionnaire):
        self.gestionnaire = gestionnaire 
        self.rappels = [] 
        self.resultatConnu = False
        self.realisation = False 
 
    def rappel(self, fct):
        if self.resultatConnu is False: 
            self.rappels.append( 
                fct 
            )
 
    def realiser(self, resultat):
        self.resultatConnu = True 
        self.resultat = resultat 
        if gestionnaire is not None: 
            gestionnaire.tache(
                self.__realisation__
            ) 
 
    def __realisation__(self): 
        if len(self.rappels)>0: 
            gestionnaire.tache(
                self.rappels.pop(0),
                self,
                rappel = self.__realisation__ # en somme : quand t'as fini, tu reviens ici voir s'il y a d'autres trucs à faire 
            )
        else:
            self.realisation = True

Pour la partie de pur test, quelques fonctions bateau (pouvant être ou non des générateurs) mais dont il est difficile à deviner l'enchaînement au premier abord avec deux promesses qui se chevauchent et se complètent.

def attendre(duree):
    print("{attendre}") 
    depart = time.time() 
    while (time.time()-depart)<duree: 
        yield 
 
def fct1(objPromesse):
    print("{fct1}") 
    objPromesse.resultat = "je suis fct1" 
 
def fct2(objPromesse):
    print("{fct2}") 
    print(objPromesse.resultat) 
 
def fct3(objPromesse):
    print("{fct3}") 
    objPromesse.resultat = "je suis fct3"
    yield from attendre(1) 
 
def fct4(objPromesse):
    print("{fct4}") 
    p1 = objPromesse.resultat 
    print("la fct4 de p2 vous dit que : ", p1.resultat) 
 
def promesse1(gestionnaire):
    print("{promesse1}") 
    p1 = Promesse(gestionnaire)
    p1.rappel(
        fct1
    )
    p1.rappel(
        fct2
    )
    return p1 
 
def realisetoi():
    p1 = promesse1(gestionnaire) 
    yield from attendre(1) 
    p1.realiser("ok pour p2")
    p2 = Promesse(gestionnaire)
    p1.rappel( 
        fct3
    )
    p2.rappel(
        fct4 
    ) 
    yield from attendre(2) 
    p2.realiser(p1) 
 
gestionnaire = Gestionnaire()
gestionnaire.tache(
    realisetoi 
)
gestionnaire.lancer()

… donnera :

{promesse1}
{attendre}
{attendre}
{fct1}
{fct2}
je suis fct1
{fct4}
la fct4 de p2 vous dit que :  je suis fct1

Surprise ! Si vous avez suivi la déclaration des fonctions de rappel pour p1, fct3() aurait dû modifier la valeur de p1 par « je suis fct3 ».

Pourquoi n'est-ce pas le cas ? Simplement la promesse ayant déjà été réalisée, on ne peut ajouter de fonction de rappel (il s'agit d'une protection logique, afin qu'il n'y ait pas une fonction qui ne soit jamais appelée - comme si elle était « oubliée »). Une exception devrait être lancée - mais par souci de pédagogie, j'ai préféré laisser cette « erreur » ne pas être gérée/affichée et le signaler.

Imaginer ce code désormais en temps réel, avec des centaines de promesses, contenant parfois des dizaines de tâches, des rappels dans tous les sens et bien sûr des liaisons de promesses entre elles… Bienvenue dans l'asynchronisme !

Bravo ! Vous avez désormais passé le plus dur. Les principaux concepts ont été expliqués (et j'espère compris). Nous allons pouvoir mettre en œuvre la mise en code standard de l'asynchronisme.

Cependant et avant de continuer, tordons le cou à quelques idées reçues et démontrons quelques hypothèses.

IV-A-1. « L'asynchronisme, c'est plus rapide… » ▲

pour a de 0 à 1000 : 
    pour b de 0 à 1000 : 
        a = a + (b/1000)

import time
 
resultats = [] 
 
for _ in range(0,10):
 
    debut = time.time()
 
    def R1(y):
        for i in range(0, 1000):
            y += (i/1000)
        return y 
 
    def R2():
        y = 0 
        for i in range(0, 1000):
            y += R1(i)
        return y 
 
    resultat = R2() 
 
    fin = time.time()
 
    resultats.append(fin - debut)
 
print(sum(resultats), "secondes")

import time
 
resultats = [] 
 
for _ in range(0,10):
 
    debut = time.time()
 
    def R1(y):
        for i in range(0, 1000):
            y += (i/1000) 
            yield
        return y 
 
    def R2():
        y = 0
        for i in range(0, 1000):
            y += yield from R1(i)
        return y 
 
    try:
        g = R2()
        while True:
            next(g)
    except StopIteration as r: 
        resultat = r.value 
    finally: 
        pass 
 
    fin = time.time()
 
    resultats.append(fin - debut)
 
print(sum(resultats), "secondes")

julien@devJG2:~/Bureau/tuto async$ python3 ref-1.py && python3 ref-2.py
3.371870994567871 secondes
9.662042140960693 secondes

IV-A-2. « …surtout pour le web !▲

IV-A-3. « L'asynchronisme est une mode » ▲

IV-A-4. « Il y a des frameworks tout prêts ; les développeurs de Python ont simplifié tout ça ; un tutoriel comme celui-là n'apporte rien »▲

Jusqu'à présent, je vous ai épargné les termes anglophones volontairement. D'abord parce qu'il y a des faux-amis de traductions, qui peuvent mal aiguiller les non-anglophones. Pourtant il faudra travailler avec… 
- Une fonction « mise en pause » avec un générateur pour la parcourir, c'est une coroutine. Le gestionnaire de tâches ou de promesses est une event loop - une boucle d'événements.
- Il est nécessaire, dans Python, par défaut, de lui signaler l'asynchronisme lors de la déclaration des fonctions qui seront des coroutines soit par un décorateur (type @asyncio.coroutine évoqué plus haut), soit par un mot-clé (async def). Lorsqu'une coroutine est appelée, il faut indiquer à Python que c'en est une soit par une fonction, soit par un mot-clé (await).
- Une event loop est toujours bloquante (ce qui est ironique, car finalement, c'est elle qui permet d'avoir du code dit « non bloquant » !). Il faut déclarer une liste de tâches arrêtée lorsque l'on travaille avec un event loop.

Vous noterez qu'il y a deux façons différentes de faire l'asynchronisme « moderne » : une version plus ancienne que l'on nomme asyncio, une bibliothèque devenue standard de Python, ainsi que les mots-clés async /await qui remplissent les mêmes fonctions de parcours automatique (gestion des StopIteration, etc.). Or il n'y a pas d'obligation, sinon pour des raisons de praticité et sur quelques points de performance, de ne passer que par eux : nous venons de faire tout un tutoriel sans !

Préférez toujours un code lisible, dans quel il est facile de comprendre, que des hauts niveaux d'abstraction qui certes, permettent une programmation plus rapide à écrire, mais n'offre pas toujours en retour une bonne vision de ce qu'un code lisible par l'humain devrait être. Les raisons qui poussent à l'utilisation de asyncio et du couple await/async, tournent souvent autour de la volonté de se rapprocher d'une écriture séquentielle. Cela induit trop souvent les personnes en erreur !

Si vous avez bien suivi ce tutoriel, les deux codes ci-dessous doivent vous être très parlants et sont tirés de la documentation officielle de Python :
… grâce à un décorateur :

import asyncio
 
@asyncio.coroutine
def slow_operation(n):
    yield from asyncio.sleep(1)
    print("Slow operation {} complete".format(n))
 
 
@asyncio.coroutine
def main():
    yield from asyncio.wait([
        slow_operation(1),
        slow_operation(2),
        slow_operation(3),
    ])

… grâce aux mots-clés :

loop = asyncio.get_event_loop()
loop.run_until_complete(main())
 
import asyncio
 
async def slow_operation(n):
    await asyncio.sleep(1)
    print("Slow operation {} complete".format(n))
 
 
async def main():
    await asyncio.wait([
        slow_operation(1),
        slow_operation(2),
        slow_operation(3),
    ])
 
 
loop = asyncio.get_event_loop()
loop.run_until_complete(main())