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.
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.
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.
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 » ?
Le problème d’Asyncio, ce n’est pas la difficulté de la programmation asynchrone, déjà complexe en soi, mais sa piètre qualité. Une conception qui sacrifie la cohérence et l’universalité n’est pas si rare en Python, mais avec quelque chose comme ProactorEventLoop, on se retrouve encore aujourd’hui avec des bugs signalés il y a 5 ans qui provoquent des interruptions de service.
Quand on est dans la position de devoir l’utiliser de force, ce genre d’article est franchement difficile à prendre à la légère.
Il est difficile de généraliser, mais dans l’ensemble, de nombreuses personnes côté PO, PM et design semblaient considérer que les progrès de l’IA ouvraient davantage d’opportunités aux PO et PM.
À l’inverse, de nombreux développeurs semblaient espérer qu’avec les progrès de l’IA, ils pourraient développer de meilleurs produits seuls, sans forcément avoir besoin de PO, de PM ou de designers.
Il faudra voir comment tout cela évoluera à l’avenir haha
Il est libre de détester cela, mais l’auteur vit lui aussi à l’ère de l’IA. Ce texte de l’auteur a sans doute déjà été collecté dans les mégadonnées de l’IA.
Quel est le critère pour dire que c’est mauvais ou bon ? Même le terme « pigeon » existe parce qu’il a des contextes d’usage appropriés. Il ne faut pas se méprendre en pensant que ce monde déborde d’un amour tout rose.
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’
asynciosuscite un rejet assez marqué chez ceux qui pratiquent Python en profondeur.Il me semble avoir souvent entendu l’avis selon lequel
geventaurait 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
asynciopour 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 » ?
Parmi les sources qui décrivent le sujet, c’est le document le mieux organisé.
Le problème d’Asyncio, ce n’est pas la difficulté de la programmation asynchrone, déjà complexe en soi, mais sa piètre qualité. Une conception qui sacrifie la cohérence et l’universalité n’est pas si rare en Python, mais avec quelque chose comme
ProactorEventLoop, on se retrouve encore aujourd’hui avec des bugs signalés il y a 5 ans qui provoquent des interruptions de service.Quand on est dans la position de devoir l’utiliser de force, ce genre d’article est franchement difficile à prendre à la légère.
Il est difficile de généraliser, mais dans l’ensemble, de nombreuses personnes côté PO, PM et design semblaient considérer que les progrès de l’IA ouvraient davantage d’opportunités aux PO et PM.
À l’inverse, de nombreux développeurs semblaient espérer qu’avec les progrès de l’IA, ils pourraient développer de meilleurs produits seuls, sans forcément avoir besoin de PO, de PM ou de designers.
Il faudra voir comment tout cela évoluera à l’avenir haha
On dirait que cela évolue un peu comme JavaScript est en train de changer.
Il est libre de détester cela, mais l’auteur vit lui aussi à l’ère de l’IA. Ce texte de l’auteur a sans doute déjà été collecté dans les mégadonnées de l’IA.
La faible fiabilité d’AI Overview est bien connue, mais là c’est quand même assez grave.
Quel est le critère pour dire que c’est mauvais ou bon ? Même le terme « pigeon » existe parce qu’il a des contextes d’usage appropriés. Il ne faut pas se méprendre en pensant que ce monde déborde d’un amour tout rose.