“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ètreencoding
et mettre “é” dans unprint
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 aussiobject
et mon favori :super()
et nonsuper(ClassName, self)
. Franchement même moi ça me perturbe de taper ça. print()
n’est pas un cas particulier : écrire surstderr
, é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 deerrno
. - 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
ou2 > "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
vsxrange
,__str__
vs__unicode__
,str()
vsbytes
vsunicode
,int()
vslong()
,dict.items
vsiteritems
vsviewitems
,input()
vsraw_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éclencheNameError
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 utilisesyield
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’une 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 :)
tout le monde s’en fout mais PHP6 ne verra jamais le jour, ca passera de PHP5 à PHP7 ;)
Ouai. Et devinez sur quoi ils ont échoué ? Le support de l’unicode :)
C’est vrai que Python3 c’est du tout bon !
Enfin sauf pour cette histoire d’opérateur
%
supprimé pour les bytes. Pour avoir porté vers python3 quelques libs travaillant avec des bytes (donc des str en python2), c’est une vrai horreur de devoir multiplier les petits changements idiots du genre"ma string is : %s ?" % var
en
b"ma string is : " + var + b" ?"
Le soucis de cette remise de % tardive, c’est que le mal est fait !
Il se passera des années avant que debian passe la 3.5, si on veut faire une lib compatible python2/3, il faut la compatibilité 3.3/3.4, donc l’opération % n’est pas utilisable :’-(
Python 2, tu veux dire.
Chouette article !
Quelques typos:
– “Le texte marche
parautomatiquement” ?– “et mon favori
s”– “retourne de l’unicode”
Wooops.
@touilleMan : ouai, ne pas avoir % sur zerobin, ça a été bien chiant.
C’est vrai que Python 3 c’est top.
Il reste quelques problèmes de lib: opencv, mayavi … toujours en python 2 (snif)
Ce qui serait bien maintenant c’est mettre le paquet sur l’aspect parking et distribution car sérieux c’est le truc qui me saoule en Python.
Packaging je suppose :) Car en effet, c’est un point faible de Python. Et de tous les langages interprétés d’ailleurs.
“Les noms des modules de la stdlib sont consistants.” : cohérents ?
Indeed :)
Coin \_o< !
Petit anglicisme détecté : consistant -> cohérent (à moins que tu trouves la mastication des modules de la stdlib difficile :P)
Désolé pour cette sodomie de diptères !
Hum… Bon ben cela m’apprendra a lire en diagonale les commentaires, j’ai juste un jour de retard pour ma remarque, sorry >< !
Au moins, on était consistants tous les deux ! :-)
Ahaha tout ce que j’ai retenu c’est le gros troll sur nodejs. Enfin j’espère que c’est un troll, parce qu’en vrai le 3e node est le début du travail pour réunir io.js et nodejs. They are merging back together dude ;)
Tout à fait, et la communauté node va goutter à sa première étape de support de couches légacy et de compatibilité. Vu que sa culture a toujours été le cutting edge, je suis curieux de savoir ce que ça va donner.
@G-rom, tout comme html 5 fait suite à html 4 et xhtml.
Au final chaque dév à sa préférence, le html5 n’est utilisable que dans certains contextes et la plupart du temps seulement en partie puisque chaque navigateur implémente ce qui lui chante.
Au final tu peux prendre la remarque de sam pour du troll, mais pendant un certain temps il y aura bien 3 versions concurrentes.
Personnellement j’ai hérité d’une aversion totale envers les balises auto-fermantes non fermées depuis xhtml, chaque fois que je vois un je suis obligé de rajouter un ‘/’.
Atta c’est quand même super différent, tu parles d’une techno cliente, où le rendu HTML est fait par le client. Donc oui une fois que tu as mis le pied dans une version, pas le choix de rester retro-compatible.
Alors que io.js c’est tellement récent, que s’ils se dépêchent de merger, je ne connais pas grand monde qui ne va pas se permettre de migrer et revenir sur node. (déjà que je ne connais pas grand mode qui est passé sur io.js en prod).