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.