14:20 <discord_afpy> <foxm4sk> Ya aussi hmm 🤔 starlette et ou httpx
14:23 <discord_afpy> <foxm4sk> Je retire httpx c'est le pendant de requests en asynchrone
20:15 <discord_afpy> <deuchnord> starlette est utilisé par FastAPI
20:47 <debnet> J'aime bien FastAPI, mais j'ai du mal à sortir de l'écosystème gigantesque de Django même pour les APIs.
20:48 <debnet> C'est trop pratique.
20:48 <debnet> Mais DRF a prévenu qu'il ne supporterait pas l'évolution async de Django.
20:48 <debnet> Donc ça finira pas devenir obsolète dans le futur.
21:06 <misc> tout n'a pas besoin d'async non ?
21:07 <discord_afpy> <fred.et.rick> Django c’est un framework web non ?
21:17 <debnet> @misc Fort heureusement non.
21:17 <debnet> Et je pense que le web sync a encore de beaux jours devant soi.
21:17 <debnet> Mais quand tu as besoin de manier les deux, c'est assez difficile à venir intégrer dans un monde purement sync.
21:17 <debnet> Alors que l'inverse n'est pas vrai.
21:17 <debnet> @fred.et.rick Oui, c'est un framework web, mais avec DRF tu peux en faire un conteneur à APIs aussi.
21:18 <debnet> Django est un gros framework avec un énorme écosystème, tu peux t'en servir pour beaucoup de choses, même pour faire autre chose que du web.
21:21 <discord_afpy> <fred.et.rick> Mais du coup si tu fais du sync avec un langage comme python, t'es pas ralenti par tes accès bdd ou tes appels api externes ?
21:36 <discord_afpy> <z4cwork> j'ai du mal à voir a quoi sert a un retour api s'il y a pas la payload de l'api externes ou depuis la bdd 😄
21:37 <discord_afpy> <z4cwork> des gens qui font du celery ou du kafka par ici d'ailleurs ?
21:40 <debnet> @fred.et.rick Alors, c'est tout le principe justement.
21:40 <debnet> Le problème de l'async c'est qu'il faut que TOUTE la stack soit async.
21:40 <alain_afpy> WARNING !!! YAKAFOKON DETECTED !!!!
21:40 <debnet> Avec Django, toute la stack "transport" est async.
21:41 <debnet> Mais toute la partie base de données ne l'est pas encore, même si ça progresse.
21:41 <debnet> Mais il existe des initiatives qui couvrent déjà toute la stack de manière async.
21:41 <debnet> Notamment FastAPI avec SQLAlchemy.
21:42 <debnet> @z4c Ca sert principalement quand on veut des APIs avec de l'immédiateté.
21:42 <debnet> Notamment par exemple les flux financiers ou boursiers.
21:42 <debnet> Ou de l'instantanéité dans le milieu de l'industrie.
21:42 <debnet> Genre pour piloter un robot.
21:43 <debnet> Pour obtenir des mesures d'instruments scientifiques avec des gros flux de données.
21:43 <debnet> Bref, des cas vraiment concrets.
21:44 <discord_afpy> <z4cwork> je vois toujours pas. pardon... pour moi l'async c'est comme un ctl^z sur le clavier. ça met en background c'est tout. c'est ni plus rapide ni plus long...
21:44 <discord_afpy> <fred.et.rick> Je pensais plus à comment tu gère le fait que quand quand t'appelle la bdd, ta machine ne repond pas aux autres client alors que la bdd c'est pas sa parti
21:45 <discord_afpy> <z4cwork> @debnet t'as des exemple de code ou de projet comme ça. ça m'interesse.
21:46 <discord_afpy> <z4cwork> ah oui bah... elle fait rien la machine. sauf si tu blindes tes threads.
21:46 <debnet> Je comprends ton incompréhension, je pense que ça mérité d'être vu plus que d'être abordé d'un pur point de vue théorique.
21:46 <debnet> mérite*
21:47 <debnet> Personnellement je suis un sceptique du tout async, que je trouve stupide, c'est un peu comme le tout kubernetes qu'on voit partout en ce moment.
21:47 <debnet> Mais je reconnais les applications pratiques que ça peut avoir.
21:48 <discord_afpy> <z4cwork> apres @fred.et.rick soit ton autoroute est plus large ( genre wsgi 128 threads ) soit le c'est une voix mais t'arrive a doubler ceux qui avancent pas assez rapidement ( async i/o )
21:49 <discord_afpy> <fred.et.rick> C'est quoi l'avantage de créer plusieurs thread comparé à de l'async avec un langage comme python qui ne peut pas gérer plusieurs thread en même temps ?
21:49 <debnet> @fred.et.rick Soon.
21:49 <discord_afpy> <z4cwork> bah t'as physiquement plusieurs processus avec plusieurs copies de ton code qui tournent simultanement
21:50 <debnet> Le GIL va progressivement sauter.
21:50 <discord_afpy> <z4cwork> https://tenor.com/view/friends-phoebe-rachel-excited-yay-gif-6166752637746503456
21:50 <debnet> L'async dans Python est déjà géré en partie par multiprocessing dans Python.
21:50 <debnet> Même c'est un GROS raccourci.
21:51 <debnet> Mais effectivement l'async prendra progressivement son envol en exploitant plus généralement le matériel à disposition dans le futur.
21:51 <discord_afpy> <fred.et.rick> J'ai vue des annonces à ce sujet, mais ça n'a pas l'air d'être pour demain
21:51 <debnet> Et pas que l'async fondamentalement.
21:51 <debnet> @fred.et.rick c'est déjà possible en 3.13.beta avec un paramétrage de l'interpréteur je crois.
21:51 <debnet> Faudrait demander à vstinner.
21:51 <debnet> Qui travaille en partie là dessus, il pourra nous en dire plus.
21:52 <discord_afpy> <fred.et.rick> Mais tu parle de multi threading ou de multiprocessing du coup ?
21:53 <debnet> Les deux.
21:53 <debnet> Mais toi ce que tu vises c'est le "réel" multithreading nativement dans un seul processus de l'interpréteur.
21:53 <discord_afpy> <fred.et.rick> Je sais pas si vous voyez à quel message on répond sur irc quand on fait repondre sur discord
21:53 <debnet> Qui n'existe pas actuellement.
21:53 <debnet> Non, ça n'existe pas sur IRC, mais on devine.
21:53 <debnet> Et si j'ai un doute...
21:53 <discord_afpy> <debnet> Je peux toujours regarder ici.
21:54 <discord_afpy> <fred.et.rick> J'avoue
21:55 <discord_afpy> <fred.et.rick> Après je vise rien en particulier, j'ai commencé le web avec php, dans le genre async ça se pose la
21:56 <discord_afpy> <fred.et.rick> Mais faut reconnaître quenle modèle d'exécution 1 requête, 1 processus, ça simplifie pas mal le dev
21:56 <z4c> 😁
21:57 <debnet> En vrai ça a à la fois favorisé et handicapé Python dans le passé.
21:57 <debnet> Et plus on avance, plus ça devient un handicap.
21:57 <debnet> Qu'il est possible de détourner dans la plupart des cas.
21:58 <discord_afpy> <fred.et.rick> C'est juste que du coup avec un seul process et sans async, je vois pas trop comment servir bcp de clients sans étre impacté par les IO
21:58 <discord_afpy> <z4cwork> jusqu'a ce que t'as envie de streamer entre les requetes 🙂
21:58 <debnet> Mais avec l'essors de l'IA (et plus généralement du ML et des modèles statistiques très gourmants), ça devient vraiment handicapant.
21:59 <discord_afpy> <fred.et.rick> Ah ben oui, clairement, ça n'a pas que des avantages
21:59 <discord_afpy> <fred.et.rick> Et l'amnésie n'est pas le seul inconvénient
22:00 <discord_afpy> <z4cwork> mais les I/O de toute facon faut les attendre... sauf si tu veux servir les clients pour dire attendez ou chargement en cours.
22:00 <discord_afpy> <fred.et.rick> Oui, mais si pendant que tu les attend tu sers un autre client, c'est mieux
22:02 <discord_afpy> <z4cwork> oui mais c'est pareille dans l'autre sens. à la fin de la fin le disque, le reseau, la bdd son en serie.
22:04 <discord_afpy> <fred.et.rick> Bah le réseau, pour le coup, tu passe plus souvent à attendre que les connexion s'etablissent qu'à bouffer de la bande passante
22:04 <discord_afpy> <z4cwork> juste dans un sens tu stack, dans l'autre fifo.
22:04 <discord_afpy> <fred.et.rick> Et si le processeur peut travailler pendant que j'attend le disque, c'est pas plus mal non plus
22:05 <discord_afpy> <z4cwork> quelqu'un m'avais expliqué une fois qu'ils ont embaucher whatmille consultant à la poste pour savoir si chaque quichet devait avoir sa file ou s'il fallait une seule file pour tous et qu'ils ont changé d'avis 3 fois.
22:06 <discord_afpy> <fred.et.rick> j’ai du mal à voir le lien
22:06 <discord_afpy> <z4cwork> bah tu fais rentrer plein de monde ou pas
22:06 <discord_afpy> <z4cwork> ton processeur tout seul il sert a rien. meme s'il tourne a 100%
22:07 <discord_afpy> <fred.et.rick> là je parle plus de savoir si la personne derrière le guichet va chercher le colis dans la réserve où si elle traite le client suivant qui vient pour un retrait pendant que quelqu’un va chercher le colis
22:07 <discord_afpy> <z4cwork> c'est le meme probleme à la reserve du coup 😄
22:08 <discord_afpy> <fred.et.rick> pas pour ceux qui sont venu faire un retrait
22:08 <discord_afpy> <fred.et.rick> et pendant que quelqu’un va à la réserve, le guichet peut s’occuper des formalités
22:09 <discord_afpy> <z4cwork> t'as pas un exemple concret ?
22:11 <discord_afpy> <fred.et.rick> autre que ma bdd est pas sur la même machine et pendant que la machine qui héberge la bdd traite la requête je peux mettre d’autres trucs sur le réseaux, non
22:11 <discord_afpy> <fred.et.rick> mais ça me semble déjà être un exemple assez parlant
22:12 <discord_afpy> <fred.et.rick> si je ne fais rien en attendant le résultat de ma requête, puis que je calcule, je perd du temps par rapport à si je calcule en attendant le résultat de ma requête
22:13 <discord_afpy> <z4cwork> c'est comme ça que ça se passe dans tous les cas tu sais.
22:14 <discord_afpy> <z4cwork> regarde un peu comment fonctionne le scheduler d'un ordi. quand il y a un blocaque I/O il joue avec les priorité et switch a un autre processus.
22:14 <discord_afpy> <fred.et.rick> voilà, il fait autre chose en attendant
22:14 <discord_afpy> <z4cwork> la tu me diras que switcher de process a un prix. je te repondrais que ce prix est le meme que la coroutine ou la GIL
22:14 <discord_afpy> <fred.et.rick> sauf que python, non
22:16 <discord_afpy> <z4cwork> euuh comment ça non. fait un `time.sleep(xxx)` tu veras que ton ordi continue a fonctionner 😄
22:16 <discord_afpy> <fred.et.rick> oui, mais ton serveur web python, il traite pas tes autres requêtes pendant ce temps là
22:17 <discord_afpy> <fred.et.rick> puisqu’il s’est juste fait mettre en pause par l’os
22:17 <discord_afpy> <z4cwork> si si si ... d'ou je te parle d'autoroute ... avec plusieurs voies. pendant que l'une est bloquée les autres continuent a rouler.
22:18 <discord_afpy> <z4cwork> ça fork et ça roule et ça fork ... et chaque requete est un process litteralement.
22:19 <discord_afpy> <fred.et.rick> du coup tu traite chaque requête dans un processus différent?
22:21 <discord_afpy> <z4cwork> oui. avec x workers a chaque fois. avec une formule savante de x par raport au caré de je sais plus quoi de la ram.
22:21 <discord_afpy> <fred.et.rick> comme en PHP en gros ?
22:22 <discord_afpy> <z4cwork> exactement. wsgi, usgi ou cgi-bin en C ou autre
22:23 <discord_afpy> <fred.et.rick> mais du coup tu te retrouve avec les mêmes genres de pb que cité plus haut https://discord.com/channels/840037163965349918/840037163965349924/1183165717588226069
22:24 <discord_afpy> <z4cwork> https://tenor.com/view/whoa-loop-endless-keanu-reeves-gif-15914657
22:27 <discord_afpy> <z4cwork> le seul truc qui me fait faire de l'async ( pour l'instant, peut être que je me trompe ) c'est quand c'est du streaming: les notifications en temps réel, la messageries entre les utilisateurs, conference, voix, vidéo...
22:29 <discord_afpy> <z4cwork> ah si un autre cas aussi. j'avais fait une api qui devait regrouper les resultants de plusieurs dizaines d'apis externes à chaque fois.