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.