[F] [mOved] Mon langage est mieux que le tien - Page 168

L'implémentation de HT s'est améliorée depuis les débuts où il avait été montré que des workloads comme MySQL détestaient l'hyperthreading, avec des pertes de performance significatives. Il reste cependant qu'en l'absence d'informations d'affinité, si le scheduler trouve malin de mettre deux threads qui utilisent les mêmes blocs du processeur sur les 2 hyperthreads du même coeur, plutôt que sur 2 coeurs séparés du même socket, la performance peut être inférieure, et surtout, non répétable.
Sur certaines micro-architectures, la performance inférieure peut aussi être remarquée quand on utilise tous les threads du CPU: la performance de memtest86+ (scheduler statique trivial) avec tous les threads est inférieure à la performance avec 1 seul thread par coeur, malgré une consommation électrique et un dégagement de chaleur habituellement supérieurs. `rep stosl / rep stosq`, ou de courtes boucles similaires, ne s'exécutent pas toujours (voire pas souvent ?) efficacement en parallèle sur 2 hyperthreads du même coeur. La pénalité de l'utilisation du SMT est certes inférieure à celle qu'on rencontre sur certaines machines quand on ne tient pas compte du NUMA (j'ai vu un facteur 15-20 sur une machine Ivy Bridge EP quad socket !), mais elle existe.
Je pense que sur certains workloads, pour avoir des benchmarks fiables, il est encore plus simple de désactiver le SMT que de programmer d'une façon ou d'une autre l'affinité de manière à éviter le SMT.

Et côté vulnérabilités des processeurs, désactiver SMT fait partie des mitigations de L1TF ("Foreshadow-NG"), MSBDS ("Fallout"), MFBDS ("Zombieload"), MLPDS et MDSUM ("RIDL"). Un certain nombre de mes machines tournent sans HT depuis 2018.

Pour rester sur Python, on peut dire qu'ils ont finalement bien piloté la transition de Python 2 vers Python 3. Il fait partie des langages plus utilisés, contrairement à PHP et ou Perl qui ont largement perdu de leur superbe.

S'il fait partie des langages les plus utilisés, c'est clairement pas grâce a la façon dont a été organisé la transition de la version 2 à 3, qui a servi de cas d'école de ce qu'il ne faut pas faire pour les langages qui ont suivis. Perso c'est vraiment ce qui m'a le plus refroidi vis a vis du langage pendant des années. J'avais sans arrêt des problèmes de compatibilité quand je tombais sur un programme Python a exécuter.
Je dirais que sa réussite vient surtout du fait qu'il a su trouver une bonne place en tant que langage de script à la fois généraliste (contrairement à PHP trop orienté serveur Web), pas trop bordélique (contrairement a Perl). et assez accessible pour faire une bonne porte d'entrée dans la programmation.

Autant je te rejoins sur le fait que cette transition était infernale et sans fin, autant je ne sais pas s'il y avait une façon de mieux gérer des breaking changes aussi importants que ceux qu'ils avaient à passer pour corriger plein de mauvais choix faits dans la version 2. Ils auraient pu vivre avec et ne jamais corriger (comme PHP), mais à partir du moment où ils voulaient par exemple différencier les séquences d'octets et les chaînes de caractère je ne connais aucun autre language qui a mieux opéré ce type de migration.

Je ne dis pas que la transition n'était pas nécessaire mais je suis convaincu qu'elle aurait pu être mieux organisée pour éviter de couper en deux l’écosystème pendant si longtemps.
Je ne connais pas assez Python en détail pour être sur, mais il y avait probablement moyen de s'en sortir avec des déprécations combinées à un système similaire aux édition de Rust (support de différentes version de la syntaxes par le même compilateur). Et si ce n'était techniquement pas possible de faire une transition plus naturelle, il aurait au moins fallu forcer d'avantage pour qu'elle aille beaucoup plus vite.

Zeph (./5015) :
Autant je te rejoins sur le fait que cette transition était infernale et sans fin, autant je ne sais pas s'il y avait une façon de mieux gérer des breaking changes aussi importants que ceux qu'ils avaient à passer pour corriger plein de mauvais choix faits dans la version 2.

C'est exactement ça.

Uther (./5016) :
Je ne dis pas que la transition n'était pas nécessaire mais je suis convaincu qu'elle aurait pu être mieux organisée pour éviter de couper en deux l’écosystème pendant si longtemps.
Je ne connais pas assez Python en détail pour être sur, mais il y avait probablement moyen de s'en sortir avec des déprécations combinées à un système similaire aux édition de Rust (support de différentes version de la syntaxes par le même compilateur).

Mais il y a eu plein de systèmes pour faciliter la transition, soit en transformant automatiquement ton code Python 2 en Python 3 (outil 2to3) ou le contraire (3to2). Tu pouvais également faire du code compatible Python2 et Python3 simultanément (avec import __futures__ qui ne faisait rien en Python 3 mais patchait en Python2).
Par expérience, et je ne pense pas être le seul, le plus gros problème venait des strings/byte strings de Python2.
Pour mémoire, en Python2 "toto" est une chaîne d'octets et u"toto" est un texte Unicode. "♥" ne fonctionne pas mais u"♥" fonctionne.
En Python3, "toto" est un texte Unicode et b"toto" est une chaîne d'octets. b"♥" ne fonctionne pas mais "♥" fonctionne.

En théorie, on peut donc faire une conversion automatisée en transformant les "" en b"" et les u"" en "" pour avoir du Python3 valide… sauf que beaucoup de code Python2 mélangeait allègrement u"" et "" (car la conversion de "" en u"" pouvait être transparente). Je pense que c'était une des principales sources de bugs en Python2, surtout quand avec des caractères accentués.

Le gros problème restant qui n'a pas été corrigé par Python3 reste celui de la portée des variables, mais en pratique il est très rarement rencontré (et encore plus avec des IDE dignes de ce nom* qui vont te bouffer les doigts quand tu fais ce genre de choses).

Et si ce n'était techniquement pas possible de faire une transition plus naturelle, il aurait au moins fallu forcer d'avantage pour qu'elle aille beaucoup plus vite.

C'est dangereux de forcer une communauté qui ne te doit rien. De plus, en pratique, à part quelques bibliothèques (surtout liées au réseau, qui manipulent souvent texte et chaînes binaires), la transition a été lente mais pas tant que ça. Ça fait très longtemps (au moins 8-9 ans) que je n'utilise plus que du Python 3.


[*] Je sais, je suis pénible avec PyCharm, mais j'ai fréquemment rencontré des personnes qui sont persuadées d'être plus efficaces avec Notepad++, Emacs (ou Vim, pas de jaloux), et qui se retrouvent à corriger des bugs qui auraient été immédiatement affichés par PyCharm… (et il y a 10 ans, quand j'ai évalué PyCharm, aucun autre IDE n'arrivait à la hauteur).

JetBrains sont d'imbatables caмarades

Lionel Debroux (./5011) :
L'implémentation de HT s'est améliorée depuis les débuts où il avait été montré que des workloads comme MySQL détestaient l'hyperthreading, avec des pertes de performance significatives. Il reste cependant qu'en l'absence d'informations d'affinité, si le scheduler trouve malin de mettre deux threads qui utilisent les mêmes blocs du processeur sur les 2 hyperthreads du même coeur, plutôt que sur 2 coeurs séparés du même socket, la performance peut être inférieure, et surtout, non répétable.
Sur certaines micro-architectures, la performance inférieure peut aussi être remarquée quand on utilise tous les threads du CPU: la performance de memtest86+ (scheduler statique trivial) avec tous les threads est inférieure à la performance avec 1 seul thread par coeur, malgré une consommation électrique et un dégagement de chaleur habituellement supérieurs. `rep stosl / rep stosq`, ou de courtes boucles similaires, ne s'exécutent pas toujours (voire pas souvent ?) efficacement en parallèle sur 2 hyperthreads du même coeur. La pénalité de l'utilisation du SMT est certes inférieure à celle qu'on rencontre sur certaines machines quand on ne tient pas compte du NUMA (j'ai vu un facteur 15-20 sur une machine Ivy Bridge EP quad socket !), mais elle existe.
Je pense que sur certains workloads, pour avoir des benchmarks fiables, il est encore plus simple de désactiver le SMT que de programmer d'une façon ou d'une autre l'affinité de manière à éviter le SMT.

Et côté vulnérabilités des processeurs, désactiver SMT fait partie des mitigations de L1TF ("Foreshadow-NG"), MSBDS ("Fallout"), MFBDS ("Zombieload"), MLPDS et MDSUM ("RIDL"). Un certain nombre de mes machines tournent sans HT depuis 2018.

Merci pour l'info. Je comprends mais je suis quand-même étonné que le HT puisse être moins performant que sans, il faut des cas où les composants partagés comme l'ALU et le cache local (je crois) soient starvés constamment pour que ça se passe, et même dans ce cas ça ne devrait pas augmenter en chaleur (on perd juste l'overhead du multithread). Mais il doit y avoir quelque chose d'autre avec l'architecture Core, parce que deux "threads" consomment en effet assez proche de deux cores distincts pour des gains largement inférieurs, ce qui n'a pas beaucoup de sens pour moi. Mon PC ne tape pas dans la limite de TDP donc je ne peux pas tester, mais il se pourrait qu'un scheduleur mettant par erreur quelque chose sur un deuxième thread puisse faire consommer plus que s'il l'avait mis sur un core non utilisé, rapporté au bénéfice de performance. Mais je crois que Windows ne fait pas ça, il remplit d'abord tous les cores avant de balancer sur les threads. L'exception, c'est pour la performance single core, mais là aussi c'est un "bug" d'Intel, qui fait que si tu bouges souvent un seul thread d'un core à l'autre comme Windows le fait, le processeur va limiter le turboboost, pensant que plusieurs cores sont utilisés (et la fréquence maximale n'est atteignable qu'avec un seul core à la fois). À l'époque j'avais désactivé le HT pour augmenter un petit peu la performance single core, au prix d'environ 30% en multicore. J'imagine qu'il peut y avoir pas mal de problèmes de ce type avec le big.LITTLE, en pire.

Quoi qu'il en soit, c'est sûr que c'est malhonnête d'Intel de faire du HT, vaut mieux vendre ses proços TTC

flanker (./5017) :
Mais il y a eu plein de systèmes pour faciliter la transition, soit en transformant automatiquement ton code Python 2 en Python 3 (outil 2to3) ou le contraire (3to2). Tu pouvais également faire du code compatible Python2 et Python3 simultanément (avec import __futures__ qui ne faisait rien en Python 3 mais patchait en Python2).

Les outils d'aide à la migration c'est vraiment indispensable, mais ça ne résout qu'une partie du problème. Le vrai soucis c'est la cassure nette dans l'écosystème, ce que la majorité des autre langages a réussi à éviter. Le code compatible à la fois Python 2 et 3, si ça peut paraitre une bonne idée a première vue, ça contribue aussi a rendre la transition floue.
Pour prendre l'exemple de Rust que j'ai bien suivi, je trouve qu'ils ont fait un choix plutôt malin. Le même compilateur peut traiter des fichiers Rust en utilisant au choix la syntaxe de l'édition 2015, 2018 ou 2021 et les lier entre eux de manière totalement transparente. Ils ont aussi fait des outils pour faciliter la migration vers les nouvelles éditions et les projets crées par cargo (l'outil standard de build et gestion des dépendances) utilisent par défaut la dernière édition.
Utiliser la dernière édition est on ne peut plus naturel, et dépendre d'une bibliothèque non migrée n’est jamais un frein. Au final, à part quelques débutants qui copient/collent sans réfléchir un bout de code fait pour une ancienne édition dans un projet qui utilise une édition plus récente, il n'y a eu quasiment aucun soucis.

flanker (./5017) :
C'est dangereux de forcer une communauté qui ne te doit rien. De plus, en pratique, à part quelques bibliothèques (surtout liées au réseau, qui manipulent souvent texte et chaînes binaires), la transition a été lente mais pas tant que ça. Ça fait très longtemps (au moins 8-9 ans) que je n'utilise plus que du Python 3.

C'est vrai que c'est pas forcément un bon plan de forcer une communauté, mais entre mettre le couteau sous la gorge pour migrer immédiatement et supporter un double écosystème pendant plus de 11 ans, il y a un juste milieu. Je pense qu'un calendrier de transition sur 3 ans aurait pu passer. Le fait d'avoir une limite clairement définie dès le départ aurait insité la communauté a faire rapidement la transition.
Perso j'ai encore eu des problèmes à cause de scripts de build pas compatible python 3, il n'y a pas si longtemps.

Uther (./5019) :
Les outils d'aide à la migration c'est vraiment indispensable, mais ça ne résout qu'une partie du problème. Le vrai soucis c'est la cassure nette dans l'écosystème, ce que la majorité des autre langages a réussi à éviter. Le code compatible à la fois Python 2 et 3, si ça peut paraitre une bonne idée a première vue, ça contribue aussi a rendre la transition floue.
Pour prendre l'exemple de Rust que j'ai bien suivi, je trouve qu'ils ont fait un choix plutôt malin. Le même compilateur peut traiter des fichiers Rust en utilisant au choix la syntaxe de l'édition 2015, 2018 ou 2022 et les lier entre eux de manière totalement transparente. Ils ont aussi fait des outils pour faciliter la migration vers les nouvelles éditions et les projets crées par cargo (l'outil standard de build et gestion des dépendances) utilisent par défaut la dernière édition.
Utiliser la dernière édition est on ne peut plus naturel, et dépendre d'une bibliothèque non migrée n’est jamais un frein. Au final, à part quelques débutants qui copient/collent sans réfléchir un bout de code fait pour une ancienne édition dans un projet qui utilise une édition plus récente, il n'y a eu quasiment aucun soucis.

J'avoue que je ne vois pas du tout où veux en venir
L'équivalent de ton exemple en Rust est un interpréteur Python qui peut interpréter mélanger du code Python 2 et du code Python 3, n'est-ce pas ? Ça tombe bien, c'est possible, au seul prix d'ajouter import __futures__.
Il n'est pas possible d'aller plus loin, ne serait-ce qu'à cause du problème str/unicode : dans de nombreux cas, ce qui est théoriquement la bonne solution (changer "" en b"") est souvent la mauvaise (car le développeur a eu la flemme de mettre u""). Je ne parle même pas des problèmes liés à la bibliothèque standard.

Par ailleurs, ce que tu aurais souhaité aurait au contraire mécaniquement ralenti encore plus la transition qui a été déjà trop lente : si tu n'as aucune incitation à migrer ton code (vu que c'est transparent de le garder dans une vieille version), tu ne risques pas de le migrer.

flanker (./5017) :
C'est dangereux de forcer une communauté qui ne te doit rien. De plus, en pratique, à part quelques bibliothèques (surtout liées au réseau, qui manipulent souvent texte et chaînes binaires), la transition a été lente mais pas tant que ça. Ça fait très longtemps (au moins 8-9 ans) que je n'utilise plus que du Python 3.

C'est vrai que c'est pas forcément un bon plan de forcer une communauté, mais entre mettre le couteau sous la gorge pour migrer immédiatement et supporter un double écosystème pendant plus de 11 ans, il y a un juste milieu. Je pense qu'un calendrier de transition sur 3 à 5 ans aurait pu passer. Le fait d'avoir une limite clairement définie dès le départ aurait insisté la communauté a faire rapidement la transition.[/quote]
Mais il y a eu un calendrier, simplement il n'a pas pu être tenu et le support de Python 2.7 a été prolongé de plus de 5 ans.

Perso j'ai encore eu des problèmes à cause de scripts faits pour python 2 il n'y a pas si longtemps.

Bah ça, quelque soit le langage ou la solution retenue, tu auras toujours des produits qui ne sont pas mis à jour.

Le spécificateur u"" était nécessaire à l'époque et ne l'est plus ? Pourquoi y a-t-il besoin d'une distinction ? C'est le seul langage qui fasse ça non ? L'UTF-8 est transparent.

"" etait en gros une chaine ASCII comme en C.

u"" etait pour forcer une chaine unicode.

Maintenant

"" est une chaine unicode
b"" est un nouveau truc, qui ressemble a l'ancien "" mais c'est pas vraiment pareil.

flanker (./5020) :
L'équivalent de ton exemple en Rust est un interpréteur Python qui peut interpréter mélanger du code Python 2 et du code Python 3, n'est-ce pas ? Ça tombe bien, c'est possible, au seul prix d'ajouter import __futures__.
Il n'est pas possible d'aller plus loin, ne serait-ce qu'à cause du problème str/unicode : dans de nombreux cas, ce qui est théoriquement la bonne solution (changer "" en b"") est souvent la mauvaise (car le développeur a eu la flemme de mettre u""). Je ne parle même pas des problèmes liés à la bibliothèque standard.

Alors je suis pas un expert python, loin de là donc n’hésite pas a me corriger si j'ai faux, mais de ce que j'avais compris, il est problématique de faire que un code conçu spécifiquement pour du Python 2 s’appuie sur des bibliothèques conçues spécifiquement pour du Python 3, et vice versa, sans modification spécifiques dans le code de l'un ou de l'autre. Rust n'a pas ce genre de problème : une crate (l'équivalent du package) a un numéro d'édition, ce qui permet au compilateur de savoir quelle syntaxe appliquer aux fichiers source. Le compilateur peut donc compiler et lier, des crates d'éditions différentes. Lors de la migration, on part d'un code clean dans l'édition précédente pour arriver a un code clean dans la nouvelle édition sans se soucier d'adapter le code pour conserver la rétro-compatibilité. Le fichier manifeste de la crate doit juste à déclarer son numéro d'édition, qui est initialisé à la dernière édition gérée par cargo (l'outil standard de build et de gestion des crate).

flanker (./5020) :Par ailleurs, ce que tu aurais souhaité aurait au contraire mécaniquement ralenti encore plus la transition qui a été déjà trop lente : si tu n'as aucune incitation à migrer ton code (vu que c'est transparent de le garder dans une vieille version), tu ne risques pas de le migrer.

C'est vrai que l'incitation a migrer est moins forte, mais c'est aussi le cas de l'incitation à ne pas migrer. C'est beaucoup plus simple pour un mainteneur de crate de prendre la décision de migrer quand l'on sait qu'on aura pas besoin de se soucier de problèmes causés par les dépendances et qu'on en causera pas a ceux qui dépendent de nous. Dans la pratique quasiment toutes les crates Rust maintenues font la transition dans les mois qui suivent la sortie d'une édition.

Uther (./5023) :
Alors je suis pas un expert python, loin de là donc n’hésite pas a me corriger si j'ai faux, mais de ce que j'avais compris, il est problématique de faire que un code conçu spécifiquement pour du Python 2 s’appuie sur des bibliothèques conçues spécifiquement pour du Python 3, et vice versa, sans modification spécifiques dans le code de l'un ou de l'autre.

Si tous tes codes fonctionnent avec Python 2 et Python 3, il n'y a aucun souci à utiliser Python 2 ou Python 3. Mais c'est sûr qu'à partir du moment où un code utilise des spécificités de Python 2 ou 3, tu es obligé d'utiliser le bon interpréteur.

Rust n'a pas ce genre de problème :[...]

Il y a deux différences fondamentales : le côté compilé de Rust d'une part, et d'autre part Rust ne correspond qu'au langage (et éventuellement au compilo) alors que Python fait référence à la fois au langage, à l'interpréteur et à la bibliothèque standard.
En pratique, très souvent le problème viendra de la bibliothèque standard.
Imaginons que ton code utilise class_A de la bibliothèque standard, au travers de lib_A (et pensé pour la bibliothèque standard de Python 2) et de la lib_B (pensé pour la bibliothèque standard de Python 3) et qu'il y a eu un changement incompatible entre les deux versions, tu auras forcément des problèmes. Je pense que tu auras le même problème en Rust si tes dépendances se basent sur des versions incompatibles de la libstd.

flanker (./5020) :Par ailleurs, ce que tu aurais souhaité aurait au contraire mécaniquement ralenti encore plus la transition qui a été déjà trop lente : si tu n'as aucune incitation à migrer ton code (vu que c'est transparent de le garder dans une vieille version), tu ne risques pas de le migrer.

C'est vrai que l'incitation a migrer est moins forte, mais c'est aussi le cas de l'incitation à ne pas migrer. [/quote]
Je ne comprends vraiment pas ce que tu veux dire.
Tu reproches de ne pas avoir assez d'incitation à migrer en prolongeant le maintien de Python 2, et tu proposes d'encore moins inciter à migrer en gardant la compatibilité avec Python 2.

C'est beaucoup plus simple pour un mainteneur de crate de prendre la décision de migrer quand l'on sait qu'on aura pas besoin de se soucier de problèmes causés par les dépendances et qu'on en causera pas a ceux qui dépendent de nous.

Mais ce n'est pas faisable à cause de la bibliothèque standard.

Dans la pratique quasiment toutes les crates Rust maintenues font la transition dans les mois qui suivent la sortie d'une édition.

Mais c'est pareil en Python : les codes activement maintenus font la migration très vite, sauf quelques rares exceptions (liées au réseau et le problème u"" / "", rendant la migration de grosses bases de code impossible à faire automatiquement et progressivement). Les passages de versions mineures sont généralement transparentes.

Quant au code qui n'est plus maintenu, il ne risque pas de migrer, en effet.

flanker (./5024) :
Il y a deux différences fondamentales : le côté compilé de Rust d'une part, et d'autre part Rust ne correspond qu'au langage (et éventuellement au compilo) alors que Python fait référence à la fois au langage, à l'interpréteur et à la bibliothèque standard.

Je ne pense pas que le coté compilé de Rust change grand chose au problème, on peut interpréter du Rust, tout comme on peut compiler du Python. Par contre je ne serais pas surpris que des fonctionnalités spécifiques du Python posent problème comme le typage dynamique. Je sais qu'en Rust certaines propriétés du système de type sont condamnées à rester comme elles sont pour que les traits définis dans une édition puissent être implémentés dans l'autre.

La bibliothèque standard de Rust fait aussi partie du langage. Par contre, si le fonctionnement de certains des éléments de la bibliothèque ne convient plus, ces éléments sont juste dépréciés et remplacés par d'autres. Pas besoin d’édition pour ça.
C'est quand même un problème avec une portée un peu différente en Rust car le langage a fait le choix d'avoir une bibliothèque standard peu chargée, comparativement au Python, même si elle reste bien plus complète que celle du C.

flanker (./5024) :
Tu reproches de ne pas avoir assez d'incitation à migrer en prolongeant le maintien de Python 2, et tu proposes d'encore moins inciter à migrer en gardant la compatibilité avec Python 2.

Ce que je veux surtout limiter dans la durée, c'est la situation ou on a deux dialectes parallèles pas directement compatibles. S'il n'y avait pas de problème d'incompatibilité, la situation ne me gênerait pas vraiment.
Dans le cas de Rust, même si on a deux syntaxes différentes, il n'y a pas d'incompatibilité au niveau de l'écosystème. Avec un compilateur récent, on est censé pouvoir compiler toutes les crates Rust qui sont sorties depuis la version 1.0 du langage.

Avec python on aurait pu imaginer bundler python 2 et sa bibliothèque dans python 3, et les scripts python 3 doivent mettre une directive pour passer à la version 3 (ou alors on change un truc comme le mot clé import, de sorte à ce que ce soit facilement reconnaissable). Et tu émets une note d'EOL pour python2 et un warning les 2 dernières années quand l'interpréteur trouve un script python 2 soit dans une dépendance soit lorsqu'il exécute un script python 2.

Mon PC (Windows) encore aujourd'hui si je tape python dans la ligne de commande ça lance python2 (qui a été installé automatiquement pour certains outils genre peut-être node-gyp), je dois faire python3 pour exécuter mes scripts, et des fois j'oublie et j'ai des erreurs bizarres. 4 ans après l'EOL, c'est une situation qui est clairement déplorable.

Ben si le coté compilé a une importance cruciale.

Tu peux lié de l'ASM, C, C++, Rust et tous les languages compilé natif auquel tu peux penser parcequ'a la fin ca reste du code binaire pour la machine cible.

Ce n'es tpas le cas de python. Pour supporter du code Python2, il faut lau moins des bouts de l'interpréter P2 dans ton P3.

Même en compilant, on ne peut pas lier n'importe quel binaire avec n’importe quel autre : il faut qu'ils aient une ABI commune et Rust ne garantit pas, par défaut, la stabilité de l'ABI. On peut certes, comme en C++, utiliser ponctuellement l'ABI stable du C, mais c'est normalement juste pour permettre de s'interfacer avec d'autre langages car on limite les fonctionnalités comme les types génériques.

Pour faire fonctionner son système d’édition, Rust nécessite en effet que le compilateur sache traiter les deux dialectes, mais ça n'a rien d'insurmontable. Les deux édition ne sont différenciées qu'au niveau de l'analyse syntaxique et lexicale. Pour le reste de l'analyse et de la génération du binaire, le compilateur utilise diverses formes intermédiaires du code à compiler, communes à toutes les éditions. Rien n’empêche un interpréteur de faire de même. Les interpréteurs un minimum performant utilisent généralement déjà une ou plusieurs représentations intermédiaires.

Uther (./5028) :
Même en compilant, on ne peut pas lier n'importe quel binaire avec n’importe quel autre : il faut qu'ils aient une ABI commune et Rust ne garantit pas, par défaut, la stabilité de l'ABI. On peut certes, comme en C++, utiliser ponctuellement l'ABI stable du C, mais c'est normalement juste pour permettre de s'interfacer avec d'autre langages car on limite les fonctionnalités comme les types génériques.

Pour faire fonctionner son système d’édition, Rust nécessite en effet que le compilateur sache traiter les deux dialectes, mais ça n'a rien d'insurmontable. Les deux édition ne sont différenciées qu'au niveau de l'analyse syntaxique et lexicale. Pour le reste de l'analyse et de la génération du binaire, le compilateur utilise diverses formes intermédiaires du code à compiler, communes à toutes les éditions. Rien n’empêche un interpréteur de faire de même. Les interpréteurs un minimum performant utilisent généralement déjà une ou plusieurs représentations intermédiaires.

Malheureusement, ce n'est pas possible de faire ça en Python à cause :
- de la gestion fondamentalement différente des string/bytes
- de la bibliothèque standard

Mais honnêtement, il y avait vraiment beaucoup d'outils de conversion qui font qu'avec un code propre de Python2, le changement était assez facile.

Je vois pas trop pourquoi les string / bytes posent problème, c'est bien deux types différents qui peuvent être traités différemment non ? Si j'ai bien compris, les chaines littérales sont par défaut des byte en Python 2 et des strings en Python 3. Si un programme Python 3 pouvait faire appel, dans un module traité en tant que Python 2, à une variable non spécifiée comme String, il recevrait un byte qu'il devrait convertir s'il veut pouvoir l'utiliser en tant que String, et vice versa.
Quant à la bibliothèque standard, comme je l'ai dit plus haut, les composants changés auraient certainement pu être dépréciés et remplacés par des nouveaux.

Tu dois quand-même inclure deux versions de l'interpréteur si tu fais ça. Certes que la partie qui transforme le texte en forme intermédiaire (pour faire du JIT ; pas sûr que Python fasse ça d'ailleurs), mais c'est pas mal. Et pareil, la bibliothèque n'a pas grand chose en commun je crois. Mais quoi qu'il en soit je suis étonné qu'il n'y ait pas eu un fork qui fasse ça, ou qu'il n'ait pas pris.

Uther (./5030) :
Je vois pas trop pourquoi les string / bytes posent problème, c'est bien deux types différents qui peuvent être traités différemment non ? Si j'ai bien compris, les chaines littérales sont par défaut des byte en Python 2 et des strings en Python 3. Si un programme Python 3 pouvait faire appel, dans un module traité en tant que Python 2, à une variable non spécifiée comme String, il recevrait un byte qu'il devrait convertir s'il veut pouvoir l'utiliser en tant que String, et vice versa.

Non, parce que tu as un comportement fondamentalement différent.
En Python2, la concaténation d'un string et d'un bytestring donne un string, ce qui fait beaucoup de développeurs ont mis des bytestring au lieu de string, comptant sur cette conversion magique pour obtenir des string quand c'était nécessaire.
En Python3, cette concaténation ne fonctionne volontairement pas.
Il n'y a aucun moyen de deviner automatiquement si le développeur voulait vraiment utiliser des bytestring ou s'il avait eu la flemme de taper le préfixe u.

D'une manière générale, il n'était pas possible de modifier Python3 pour le rendre compatible Python2, principalement à cause de ce vice de conception. Ils ont donc décidé de faire l'inverse : modifier Python2 pour le rendre compatible Python3, avec des modules de compatibilité pour que le même code fonctionne à la fois en Python2 et Python3.

Quant à la bibliothèque standard, comme je l'ai dit plus haut, les composants changés auraient certainement pu être dépréciés et remplacés par des nouveaux.

C'est rigolo, parce que tu râles sur la lenteur de la transition, et tu proposes plein de solutions pour qu'elle prenne encore plus de temps
Mais au final, tu n'as pas trente-six solutions possibles : soit tu acceptes de modifier ton code pour passer à Python 3 (et dans ce cas, il y avait vraiment tous les outils à ta disposition pour faire une transition franche ou progressive), soit tu ne veux pas toucher à ton code, et ça ne sert à rien de faire une version Python3 compatible Python2 (à part retarder l'échéance inéluctable de la perte de compatibilité).

flanker (./5032) :
Non, parce que tu as un comportement fondamentalement différent...

Je ne vois toujours pas en quoi le fonctionnement différent serait un point bloquant, je ne dis pas qu'il n'y a pas des particularités qui m'échappent quelque-part, mais l'exemple que tu donnes ne me parait pas particulièrement problématique.
Encore une fois, il ne s'agit pas de mélanger python 2 et 3 dans un même package. Un package serait soit en python 2 soit en python 3. C'est juste que des packages de versions majeures différentes pourraient être traités par le même interpréteur et interagir l'un avec l'autre. Mais l’intérieur d'un package Python 2, les règles de la version 2 s'appliqueraient (notamment pour la concaténation) alors que les package en version 3 appliqueraient leurs règles.
Ce qui est possiblement le plus problématique, c'est le système de type. Il faudrait s'assurer qu'il permet bien une interface entre du code en version 2 et 3.

flanker (./5032) :C'est rigolo, parce que tu râles sur la lenteur de la transition, et tu proposes plein de solutions pour qu'elle prenne encore plus de temps

Je pense pas que la quantité de code modifié soit ce qui freine le plus une migration. Avec les outils d'assistance à la compatibilité, ça va assez vite.
Pour moi ce qui bloque vraiment les transitions, c'est la prise en compte des risques d'incompatibilité que l'on peut subir en amont et provoquer en aval, car c'est des facteurs que l'on ne maitrise pas.

Brunni (./5031) :
Tu dois quand-même inclure deux versions de l'interpréteur si tu fais ça. Certes que la partie qui transforme le texte en forme intermédiaire (pour faire du JIT ; pas sûr que Python fasse ça d'ailleurs), mais c'est pas mal. Et pareil, la bibliothèque n'a pas grand chose en commun je crois. Mais quoi qu'il en soit je suis étonné qu'il n'y ait pas eu un fork qui fasse ça, ou qu'il n'ait pas pris.

Python peux « compiler » le code dans un bytecode (les fichier .pyc) et je doute que ça soit compatible entre P2 et P3, et je ne serait os surpris que même entre différentes versions de Python 3 il ne puisse pas y avoir des incompatibilités

Uther (./5033) :

flanker (./5032) :
Non, parce que tu as un comportement fondamentalement différent...

Je ne vois toujours pas en quoi le fonctionnement différent serait un point bloquant, je ne dis pas qu'il n'y a pas des particularités qui m'échappent quelque-part, mais l'exemple que tu donnes ne me parait pas particulièrement problématique.
Encore une fois, il ne s'agit pas de mélanger python 2 et 3 dans un même package. Un package serait soit en python 2 soit en python 3. C'est juste que des packages de versions majeures différentes pourraient être traités par le même interpréteur et interagir l'un avec l'autre. Mais l’intérieur d'un package Python 2, les règles de la version 2 s'appliqueraient (notamment pour la concaténation) alors que les package en version 3 appliqueraient leurs règles.
Ce qui est possiblement le plus problématique, c'est le système de type. Il faudrait s'assurer qu'il permet bien une interface entre du code en version 2 et 3.

Ça veut quand même dire créer un interpréteur Python qui embarque à la fois Python 2 et Python 3. Très compliqué à faire techniquement, contraire à l'objectif de Python 3 (débarrasser Python des erreurs de Python 2), avec un intérêt somme toute très limité en pratique (la plupart des projets maintenus ont migré relativement rapidement). Et à nouveau, je ne vois pas comment cela aurait pu accélérer la transition : donner une solution pour rester encore plus longtemps à Python 2 n'est certainement pas une incitation à migrer.

flanker (./5032) :C'est rigolo, parce que tu râles sur la lenteur de la transition, et tu proposes plein de solutions pour qu'elle prenne encore plus de temps

Je pense pas que la quantité de code modifié soit ce qui freine le plus une migration. Avec les outils d'assistance à la compatibilité, ça va assez vite.
Pour moi ce qui bloque vraiment les transitions, c'est la prise en compte des risques d'incompatibilité que l'on peut subir en amont et provoquer en aval, car c'est des facteurs que l'on ne maitrise pas.[/quote]
En pratique, ce n'est pas ce que j'ai vu sur les paquets Python majeurs qui ne migraient pas. Les principaux arguments que j'ai vu portaient
- sur la complexité à migrer le bazar entre string/bytestring (et plus le code était gros, plus c'était compliqué),
- sur les bugs mis en évidence par Python 3, bugs de conception qu'il fallait donc corriger,
- sur l'absence en Python 3 de certaines dépendances critiques,
- sur le besoin de rester compatible avec les clients restant en Python 2.4 (coucou Ansible), avec plus ou moins de mauvaise foi d'ailleurs.

flanker (./5032) :Les principaux arguments que j'ai vu portaient
- sur la complexité à migrer le bazar entre string/bytestring (et plus le code était gros, plus c'était compliqué),
- sur les bugs mis en évidence par Python 3, bugs de conception qu'il fallait donc corriger,
- sur l'absence en Python 3 de certaines dépendances critiques,
- sur le besoin de rester compatible avec les clients restant en Python 2.4 (coucou Ansible), avec plus ou moins de mauvaise foi d'ailleurs.

Sur les deux premiers points, en effet un système similaire aux éditions de Rust ne changerait probablement pas grand chose. Mais c'est plus un problème de qualité de l'existant que de migration.

Sur les deux derniers par contre, ça résout clairement le problème.

Oui, mais à nouveau ça ralentirait la migration au prix d’une complexité monstrueuse, pour une utilité qui reste à réellement démontrer.

Tout d'abord, avec un système d'édition, le fait qu'un programme ne soit pas migré n'est pas problématique. C'est juste les mainteneurs qui devront souffrir un fonctionnement daté, mais c'est leur propre choix, et ils ne l'imposeront pas aux autres. Par contre la séparation de l'écosystème pose de vrais problèmes : pour les développeurs qui veulent migrer mais ne le peuvent pas à cause des dépendances en amont ou en aval, et pour les utilisateurs finaux qui ont à gérer plusieurs versions de l'interpréteur en fonction du code a exécuter.

Ensuite, je reste persuadé que retirer la contrainte des dépendances aurait globalement accéléré la transition et non ralenti. Je sais que la comparaison est pas forcément pertinente sur tous les points, mais si on regarde la transition significative de l'édition 2015 à 2018 de Rust (la suivante était vraiment mineure), elle c'est faite très vite pour tous les projets maintenus, bien que ça n'aurait gêné personne si ça n'avait pas été le cas. En Python, les soucis de dépendances en cascade font que l'on avait encore des programmes significativement utilisés qui posaient problème des années après. Tu as cité le cas de Ansible, mais c'était loin d'être le seul.

Pour ce qui est de la complexité additionnelle pour l’interpréteur, je pense que ça aurait pu être être fait de manière tout à fait gérable, en tout cas si ça avait été pensé dans ce sens dès le début. Il ne s'agirait pas d'avoir deux interpréteurs très différents complétement séparés, mais une première couche qui convertit tout en une base commune tôt dans le processus d'analyse. Là encore, la comparaison n'est peut-être pas vraiment valable, mais les développeurs du compilateur Rust sont assez d'accord pour dire qu'ils n’envisagent pas de retirer le support des vieilles éditions, même pas dans un futur éloigné vu que la complexité ajoutée par le système d'édition est vraiment minime. Le gros de la complexité du compilateur (système de type, analyse de la durée de vie des variable, optimisations, génération du binaire, ...) a lieu en aval.

sinon faire un vrai split, changer l'extension des scripts et la source des dépendances, tabula rasa

deux interpréteurs séparés, comme deux langages différents

C'est plus ou moins la solution qu'a adopté Perl 6 qui est devenu Raku : un langage séparé. Ça a clairement des avantages, mais un énorme risque : ne jamais récupérer une bonne partie de la communauté qui pourrait rester sur l'ancien écosystème.