Python 3 est fait pour les nouveaux venus


“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’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 :)

19 thoughts on “Python 3 est fait pour les nouveaux venus

  • foxmask

    tout le monde s’en fout mais PHP6 ne verra jamais le jour, ca passera de PHP5 à PHP7 ;)

  • touilleMan

    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 :’-(

  • Olivier

    Le report de la dépréciation de Python 3 de 2015 à 2020

    Python 2, tu veux dire.

  • Hub

    Chouette article !

    Quelques typos:

    – “Le texte marche par automatiquement” ?

    – “et mon favoris

    – “retourne de l’unicode”

  • Sam Post author

    @touilleMan : ouai, ne pas avoir % sur zerobin, ça a été bien chiant.

  • francoisb

    C’est vrai que Python 3 c’est top.

    Il reste quelques problèmes de lib: opencv, mayavi … toujours en python 2 (snif)

  • Doubledose

    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.

  • Sam Post author

    Packaging je suppose :) Car en effet, c’est un point faible de Python. Et de tous les langages interprétés d’ailleurs.

  • fpp

    “Les noms des modules de la stdlib sont consistants.” : cohérents ?

  • TitusCrow

    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 !

  • TitusCrow

    Hum… Bon ben cela m’apprendra a lire en diagonale les commentaires, j’ai juste un jour de retard pour ma remarque, sorry >< !

  • G-rom

    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 ;)

  • Sam Post author

    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.

  • Zanguu

    @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 ‘/’.

  • G-rom

    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).

Comments are closed.

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.