Ah, le bon vieux troll de la communauté Python ^^

Je n'ai pas *du tout* la même opinion.
D'abord, est-ce que Python est en train de mourir ? Quand on le compare à PHP ou Perl, pas franchement.
(je sais, TIOBE n'est pas terrible, mais je n'ai pas mieux)

Ensuite, Python 2 souffrait de graves erreurs de conception (la confusion entre unicode et str, notamment), qu'on ne pouvait pas résoudre sans casser la compatibilité.
Avec la même rigueur d'écriture, un code Python 3 sera moins buggué que le code Python 2 correspondant (à cause de cette énorme connerie).
Soit on passait à un nouveau langage, soit on cassait pour une fois la compatibilité, soit on conservait ces erreurs fondamentales.
À cause de ça, oui, passer un code Python 2 à Python 3 est (parfois) compliqué, justement à cause de cette confusion (et qu'en pratique, la migration corrige plein de bugs au passage).

Est-ce vraiment compliqué de passer à Python 3 ?
Par expérience, non, contrairement à ce qu'il dit, c'est facile, sachant qu'on a plein de solutions :

* écrire du code Python 2, avec 2to3 qui le convertit en Python 3,
* écrire du code Python 3, avec 3to2 qui le convertit en Python 2,
* écrire du code mixte soi-même (ça, c'est chiant),
* utiliser __futures__ qui modifie localement la grammaire de Python 2 (pour la rendre compatible avec Python 3) : on a donc un fichier écrit en pur Python 3 qui fonctionne indifféremment avec Python 2 et 3(*),
* utiliser des libs de backport en Python 2 pour certaines nouvelles libs de Python 3,
* écrire du code mixte avec une lib d'assistance (six, par exemple) pour les libs qui ont été renommées.

On peut donc migrer progressivement un code Python 2 en 3, fichier par fichier, alors que l'ensemble continue à fonctionner en Python 2.
Ça explique la lenteur de la migration, mais au moins Python n'en est pas mort.

Depuis un an environ, on passe enfin massivement à Python 3, avec un phénomène de sélection naturelle.
On se retrouve avec un langage ET un écosystème complet, mûr (packaging, déploiement, libs, tests, documentation, …) débarassé des vieux projets abandonnés.
La communauté a également beaucoup évolué, et quasiment tous les projets que je regarde sont franchement propres :

* packagés correctement et uploadés sur Pypi,
* installables via pip (packageables très facilement en rpm ou deb),
* code sur Github,
* docs générées par Sphinx et uploadées automatiquement sur ReadTheDocs,
* code respectant la PEP008 (la norme décrivant le style officiel),
* tests unitaires sur TravisCL.


Si on regarde P3 WoS (qui donne la compatibilité des lib Python les plus courantes), on voit qu'elles sont quasiment toutes compatibles Python 3, sauf

* des projets indépendants (genre Supervisor : on s'en fout qu'il soit Python 2, 3 ou écrit en C ou en Go),
* des projets morts en terme d'évolutions ou de communauté (Fabric, totalement dépassé par Ansible) et avec un équivalent moderne,
* des projets dont une version Python 3 existe (python-openid).


Oui, la transition a été (très) longue, mais c'était volontaire (le but était de faire évoluer Python 3 lentement au début en développant Python 2 en parallèle, pour éviter les erreurs de conception) et au moins ça n'a pas complètement tué Python (cf. Perl 6 : le projet est mort-né).

Bon, sinon, sa conclusion est la pire des solutions : personne ayant fait du Python 3 n'accepterait de refaire du Python 2 (avec tous les bugs qui viennent avec automatiquement). Oui, Python 2 est mort, ça n'empêche pas les projets existants de continuer à vivre)

(*) par exemple, en Python 2 print est un opérateur (print "toto"), les chaînes unicodes s'écrivent u"string" et les chaînes binaires s'écrivent "bytes";
En Python 3, print est une fonction (print("toto")), les chaînes de texte s'écrivent "string" et les chaînes binaires s'écrivent b"bytes".
Si au début de son fichier Python, on fait "from __futures__ import *", on peut utiliser la syntaxe Python 3 en exécutant Python 2 (dans ce fichier uniquement, les autres ne sont pas affectés).