Mise à jour de la base de données, veuillez patienter...

“Je n’ai pas vraiment de raison de migrer vers Python 3″ est la cause numéro 1 de la lente migration de Python 2 vers 3. 16% utilisent Python 3 comme VM principale, contre 81% pour 2.7 (on notera la part ridicule des autres versions, que vous pouvez donc ignorer dans le support de vos libs). Le report de la dépréciation de Python 2 de 2015 à 2020 a donc tout son sens : la communauté a pris son temps car le jeu n’en valait pas la chandelle.

Mais on y arrive. La plupart des libs importantes sont portées, les hostings supportent beaucoup mieux Python 3, même le portage de twisted a repris, grace à Crossbar d’ailleurs :) Perso je commence toujours mes nouveaux projets en Python 3.

On peut le dire maintenant, tout le monde a eu un peu peur. D’ailleurs Guido n’est pas prêt de recommencer. Après PHP 6 et Perl 6 qu’on attend toujours, des ralages dans tous les sens, des version 3.0, 3.1 et 3.2 vraiment à chier, après le retrait de % pour les bytes et l’appel pour une 2.8, on s’est tous demandé si ça allait pas foirer.

Maintenant, je suis certain que non. On a passé cette étape, ça a pris du temps, ça a fait mal au cul, mais pendant que Node se divise en 3 versions alors qu’il existe depuis à peine 6 ans, Python fête ses 20 ans avec une seule transition difficile, qui s’est révélée gagnante.

Mais gagnante pour qui ?

C’est vrai qu’il y a de bonnes features qui ne sont qu’en version 3 : asyncio, pathlib, statistics, ipaddress, enums, lzma, raise from, yield from, singledispatch, multiprocessing.Pool.map, @, await/async, les type hints, le support avancé des closures et l’unpacking étendu. Mais d’abord, certaines arrivent pour la 3.5, ensuite, les autres n’ont visiblement pas motivé les vieux de la vieille à faire le pas pendant 5 ans.

Pourquoi ? Parce que Python 3 n’a pas été créé pour eux. Il a été créé pour les nouveaux arrivants dans le langage.

Ayant un peu d’expérience avec le fait d’enseigner Python, je peux vous dire que faire passer Python 2 et Python 3, c’est le jour et la nuit :

• Le texte marche automatiquement la plupart du temps : on a des objets unicodes partout, utf8 est par défaut, os.truc retourne de l’unicode, open a un paramètre encoding et mettre “é” dans un print ou un commentaire marche out of the box. Ca change la vie.
• Le corolaire est qu’il y a plein de truc en moins à expliquer. u, from __future__, # coding mais aussi object et mon favori : super() et non super(ClassName, self). Franchement même moi ça me perturbe de taper ça.
• print() n’est pas un cas particulier : écrire sur stderr, éviter un saut de ligne et séparer des entrées sont juste des paramètres de fonctions et non des >> et ,.
• Les noms des modules de la stdlib sont cohérents. On peut les deviner, les découvrir et chercher de la doc plus facilement.
• La hiérarchie des exceptions est beaucoup plus claire. IOError/OSError ont des enfants qui évitent l’obscure usage de errno.
• Par ailleurs plein de messages d’erreurs sont plus explicites.
• Et des nouveaux messages d’erreur font leur apparition. On ne peut plus faire True = reponse ou 2 > "1". Cette dernière, TOUT LE MONDE me l’a faite.
• Les pyc sont groupés dans un dossier. Tellement plus clair.
• Le shell Python a l’autocompletion activée.
• / est moins surprenant. Encore un truc de moins à expliquer.
• “There is one way to do it”. Plus de range vs xrange, __str__ vs __unicode__, str() vs bytes vs unicode, int() vs long(), dict.items vs iteritems vs viewitems, input() vs raw_input().… Est-ce que vous voyez la somme de choses en moins à apprendre ? C’est colossale. Et plein de sources d’erreurs en moins. Par exemple, input() en Python 2 déclenche NameError quand on saisie des lettres. C’est super marrant, je vous raconte pas.
• Les imports sont toujours absolus. Combien de fois j’ai du dire “alors, tu as appelé ton module test.py, et ça peut pas marcher parce que…”.
• Ne pas avoir à dire “nan, tu peux pas utiliser return si tu utilises yield parce que… heu… c’est comme ça”.
• Et tous ces bugs qui arrivent parce que quelque part, l’apprenant a utilisé une old style class dans la hierarchie et on passe 20 minutes à essayer comprendre un comportement aberrant pendant que le reste de la classe est sur facebook.
• Les variables ont une portée limitée dans les compréhensions :

  for x in [1, 3, 5]: squared = [x**2 for x in (1, 2, 3, 4)] print(x)

  Affiche 1, 3, 5 en Python 3, 4 4 4 en Python 2. Certes, j’essaye d’apprendre à mes élèves à faire gaffe aux noms de variables, mais bon, y en a toujours un qui chie dans la colle, faut pas se leurrer.

Nous, utilisateurs chevronnés de la 2.7, ne nous rendons pas compte de la somme de connaissance que nous avons accumulé au fil des années pour contourner ces problèmes. Les nouveaux, même autodidactes, vont aller beaucoup plus vite.

Python 3 fait très bien son boulot : garder Python sa place de meilleur langage pour l’apprentissage. Ca tombe bien, parce qu’un fois appris, il sert aussi à plein de choses professionnellement, et pas juste du dev Web (ruby), du sysadmin (perl) ou des maths (R).

Et du coup la migration a pris du temps.

Depuis la 3.4, tout s’accélère. L’investissement est en train de payer.

Perso, quand je dois écrire du Python 2 maintenant, ça me fait râler :)