En surface, le nombre de lignes de code (LOC) compte aussi. Du point de vue de la productivité, lire et comprendre une page entière n’est pas la même chose que lire et comprendre 3 lignes.

Bien sûr, moi aussi j’utilise .asyncio jusqu’à saturation en production, mais je ne suis pas assez satisfait de l’expérience actuelle pour dire que « je l’utilise bien ».

L’asyncio actuel est conçu en partant du principe du GIL et constitue, d’une certaine manière, une stratégie pour le contourner, donc le GIL n’interagit pas directement avec asyncio.

Mais si l’on considère l’ensemble de la programmation concurrente fondée sur asyncio, je pense qu’affirmer que le GIL n’a aucun rapport revient à dire quelque chose comme : « C’est Python, donc c’est normal que ça ne marche pas. »

Je suis d’accord sur le fait qu’on ne peut pas s’attendre à ce que l’orientation actuelle autour du GIL soit à la hauteur des « autres alternatives ».
Mais dire qu’il faut adopter d’autres alternatives que Python ne devrait-il pas conduire non pas à soutenir qu’il n’y a pas de problème, mais au contraire à reconnaître qu’il y a bien un problème ?

Cette fois, j’ai essayé le développement web par simple intérêt personnel, un domaine qui n’a absolument rien à voir avec celui dans lequel je développais à l’origine. J’ai créé un forum avec le app router de next.js v15… mais à chaque fois que je vois ce genre de post, j’ai l’impression que ça me coupe toute envie de tenter quelque chose de nouveau côté web. Pourquoi l’écosystème est-il si instable ? Et puis quoi, si un nouveau truc sort, tout le monde va encore se ruer dessus, l’utiliser un peu, le critiquer, puis repartir chercher autre chose ? Le développement web a vraiment l’air difficile.

Le pouvoir et l’argent sont certes les moteurs qui font avancer un projet.
Mais il est difficile de ne pas pousser un soupir à chaque fois qu’on voit une page web qui ne fonctionne pas correctement sans Chromium.

Honnêtement... Il n’y a probablement que Google qui soit capable de maintenir Chrome à ce niveau. En plus, même si ce n’est pas au niveau des semi-conducteurs, la domination du marché des navigateurs web est aussi un domaine que les États-Unis ne veulent pas lâcher.... J’ai l’impression qu’un certain degré de monopole continuera d’être toléré à l’avenir.

Je confirme tardivement.
Merci pour votre réponse si attentionnée !

Même si l’on ressent de l’inconfort, on s’y habitue vite à force de l’utiliser, non ?
L’être humain est un animal d’adaptation.

Ce n’est pas clairement indiqué dans le texte, mais cela pourrait-il vouloir dire que, lorsqu’on écrit du code avec l’IA, il devient une dette parce qu’il est moins familier pour les humains que du code écrit directement par eux-mêmes ?

Tiens, moi aussi j’étais un utilisateur payant haha
En regardant l’historique de l’App Store, je vois que c’est devenu gratuit à partir de la version 1.51.
Pour moi, c’est un outil indispensable, car les réglages d’écran de mon MacBook changent selon l’endroit où je l’utilise.

On n’écrit pas un article scientifique non plus, alors bon…

J’ai l’impression que le GIL arrive un peu de nulle part ici… Même si le GIL était supprimé,
si l’on veut utiliser le multithreading à la fois pour les charges I/O bound et CPU bound,
il vaudrait peut-être mieux adopter une autre alternative que Python…

J’ai aussi l’impression qu’asyncio suscite un rejet assez marqué chez ceux qui pratiquent Python en profondeur.
Il me semble avoir souvent entendu l’avis selon lequel gevent aurait dû devenir le courant dominant.

Merci pour la présentation de cette excellente application.

J’ai également rédigé du contenu supplémentaire.

J’utilise beaucoup asyncio... c’est tout à fait utilisable. Il y a une limite liée au fait que l’annulation des tâches est edge-triggered (et non level-triggered), mais en réalité on écrit rarement du code qui prend vraiment en compte l’annulation des tâches tout en gérant cela proprement. Un problème plus important, c’est que l’event loop ne conserve qu’une weak reference vers les tasks, donc elles peuvent disparaître à cause du GC... mais ça se règle avec la structured concurrency.

Pour la plupart des grandes opérations d’I/O, ce n’est pas difficile de trouver des bibliothèques qui prennent en charge asyncio...

Le GIL ? Ça n’a pas grand-chose à voir. L’idée même d’utiliser asyncio pour paralléliser des tâches CPU intensive est un peu étrange. Si le GIL s’améliore, ce sera utile pour le multithreading sur des charges CPU intensive. L’async, lui, sert à faire tourner le plus efficacement possible les portions limitées par l’I/O...

Bref, conclusion : il y a bien quelques problèmes de conception, mais pour atteindre l’objectif, je l’utilise sans difficulté particulière et ça fonctionne très bien en production.

Même s’il s’agit d’une attaque MITM, comment ont-ils réussi à casser une communication HTTPS ? Est-ce que je suis le seul à ne pas comprendre ?

Je me demande quelle est la vitesse en comparaison avec Biome ?

Je vais simplement utiliser joblib.

Bien sûr, une raison plus importante est peut-être que, à cause du GIL, les gains qu’on peut obtenir au départ sont plus limités que dans d’autres environnements.
Je pense qu’affirmer qu’on peut créer une synergie s’il n’y a pas de GIL relève presque de la tromperie. Si l’on donne une prothèse, certes utile malgré l’inconfort, à un coureur à qui il manque une jambe, est-ce que c’est vraiment une « synergie » ?