robinHood (./5039) :
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

Perl a exactement fait ça. Mais le langage est mort au passage…

Uther (./5038) :
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.

En pratique, la non-migration d'Ansible n'a pas posé de problème, car il n'est pas utilisé comme bibliothèque (et tout est fait pour que ça ne soit pas possible). Ça imposait surtout de garder du Python 2 inutile à part ça.
Globalement, il n'y avait pas tellement de dépendances en cascade qui bloquaient, c'était quelques grosses dépendances (activement maintenues) et des dépendances non maintenues.

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.

Sauf que ce n'est pas possible en pratique, le fonctionnement est bien trop différent. Dans beaucoup de cas, il est impossible de manipuler la même variable en Python2 et en Python3.
Et à nouveau, ça aurait supprimé une incitation à migrer.

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.

Je pense qu'en effet, la comparaison n'est pas franchement valable.