Bien que parfois limitée par la capacité de calcul, la vitesse d'exécution d’un morceau de code est bien plus souvent limitée par des opérations d'entrées sorties qui n’en peuvent plus d’attendre. Co-routines, Futures et une nouvelle pièce au puzzle, asyncio, proposent une réponse élégante à ce problème. Cette présentation vous propose de l’explorer et de la rendre accessible au plus grand nombre.
En tant que scientifique, mon univers est constamment confronté au besoin de paralléliser pour faire plus dans un temps fini et généralement bien occupé. Bien que souvent confronté à des tâches de programmation limitées par la capacité de calcul de la machine, la vitesse d'exécution d'un morceau de code est limitée, dans de très nombreuses applications, par des opérations d'entrées sorties qui attendent une réponse, par exemple d'un serveur distant. Ici, l'utilisation de threads ou de multiprocessing n'est pas toujours la solution la plus indiquée ni la plus intuitive à implanter. Afin de répondre à cette problématique, de nombreux frameworks asynchrones ont vu le jour, comme Twisted, Tornado, ZeroMQ, gevent, pour n'en citer que quelques uns. Si chaque opus se propose d'apporter son lot de solutions à certaines problématiques spécifiques, leur interopérabilité peut être rendue difficile par l'utilisation de modèles événementiels bien différents. C'est pour répondre à ce besoin de standardisation que le PEP-3156 a été rédigé et que la bibliothèque asyncio a trouvé sa place dans la bibliothèque standard de python dès sa mouture 3.4.
Que reproche-on à asyncore? Quel sont les apports de asyncio? Que deviennent Twisted, gevent, Tornado dans cette équation? Pouvez-vous m'expliquer les générateurs, les co-routines, les Futures ou encore "yield from"? Quels problèmes ces abstractions essaient-elles de résoudre? Ce sont les questions que je me propose d'explorer avec vous, dans un style accessible au plus grand nombre.