A la sortie de Python 3.4, je vous avais dit qu’on pouvait enfin coder sereinement en Python 3. Mais en pratique, qu’est-ce que je vois dans la vie de tous les jours ?
Ca y est, je fais plus de Python 3 que de Python 2 !
50 % de mes formations, on me demande du Python 3. On ne me demande du 2 que pour des personnes coincées avec du code legacy, ou dans des domaines à la traine comme les GIS.
Quand je commence un projet, je commence toujours en python 3, sauf si je dois utiliser Twisted. Tous les autres trucs qui m’intéressent ont été portés. Et vous savez quoi ? Le portage de Twisted a repris de l’allure dernièrement, par des gens motivés par crossbar.io :)
La raison majeure qui me force à faire du Python 2 est le travail sur d’anciens projets comme des sites de culs de Max qui ont été commencé il y a des années.
Bien que je déteste toujours cordialement devoir taper ces putains de parenthèses pour faire un print, voici ce que j’adore :
- Le texte est 100X plus facile. Je n’ai plus à demander à mes élèves de ne pas mettre d’accents dans leurs programmes avant qu’on arrive à la partie du cours qui explique l’encoding.
- pip est intégré (en Python 2 aussi maintenant, mais seulement sur une version toute neuve). Et le shell autocomplète même sans ipython.
- L’unpacking avancé. C’est pratique. C’est très pratique.
- Les nouvelles exceptions : plus claires, plus facile à comprendre et à filtrer. Love.
- Le nouveau format de retour de la fonction
type(). Tellement plus logique. - Pas besoin de se poser des questions sur l’usage de
item(),iteritems(),items_view(), etc. - Plein de petits polish. Des inconsistances qu’il fallait connaître par cœur avant ont juste disparu.
En fait, à la programmation, Python 3 est plus sympa, mais pas révolutionnaire. Et puis des détails comme la suppression de % pour le type byte a bien fait chier tout le monde, et heureusement a été inversé en 3.5.
Mais par contre à enseigner… C’est juste fantastique. Pour les nouveaux venus, le changement est incroyable.
C’est clair que pour le texte c’est carrément plus simple. Et plus besoin d’utiliser codecs pour spécifier l’encodage d’un fichier ! Par contre, c’est plutôt important de le faire dans l’appel à open (ce sont les seules erreurs liées à l’encodage que je rencontre depuis que je suis passé à py3).
Pip faisant partie de la distribution, ça aide bien pour pousser python dans un milieu pro pas forcément sensibilisé aux technos efficaces :-).
Ne pas avoir à étendre object pour chaque classe, c’est cool aussi.
Ce sont des petits détails qui peuvent me rendre un peu chiant le retour à la 2.7.
Tout en 3.4 64bit (sauf quand je dois me farcir du legacy).
J’ai par contre essayé d’utiliser py2exe et cxfreeze avec la V3, c’est juste l’enfer sur terre. A mon sens, c’est justement les problèmes pour packager et distribuer qui explique la relative impopularité de python chez les non-initiés.
Pas mal de softs/scripts du domaine de la recherche (bioinformatique, pour ma part) sont en python 2. Et ça ne changera pas avant quelques lustres.
Éthiquement, la meilleure solution est de spammer l’import de future.
C’est largement suffisant pour la majorité des codes python. En bioinfo en tout cas.
La cheatsheet de python-future est vachement complète : http://python-future.org/compatible_idioms.html
Mouahah j’ai été elevé sur python3 et je n’ai jamais connu python 2 =D, j’en ai juste une idée globale histoire de piger un peu les scripts ramassés sur le net, python3 ça a l’air plus cool que python2 par rapport au peu que j’en sais, et perso ça me va !
Idem, ça fait un moment que je ne fais plus que du 3 sauf pour un projet django qui y passera dès que j’ai un peu de temps à consacrer à cette migration.
La manipulation du texte c’est juste du bonheur.
Dans le domaine de l’admin, avec des serveurs hétérogènes dont certains ont des vieilles versions d’OS, ici c’est du Python 2. Et si je dois changer, je pars sur du Golang, j’en ai un peu marre de n’utiliser qu’un core, et de galérer à chaque fois quand je dois packager un programme.
from past import print_statement :'(
Dans ipython on peut faire :
Et les parenthèses deviennent optionelles. Faut pas en abuser (on est pas rubistes), mais pour print c’est pratique.
L’auto-complétion est supportée depuis un bail (Py2.6) via le module rlcompleter, si je ne me trompe pas.
import rlcompleterrlcompleter.readline.parse_and_bind("tab: complete")
Et pip est supporté depuis un bail, il suffit de l’installer. Et l’utf8 et supporté depuis un bail, il suffit de mettre un en-tête, et les litteraux unicodes sont supportés depuis un bail, il suffit d’importer future, et la division flottante est supportée depuis un bail, il suffit de faire operator.truediv, etc, etc. Python 2.7 était déjà turring complet, pourquoi passer à Python 3 ?
Parce que c’est plus pratique de pas avoir à faire tout ça, banane.
Moi, j’ai un peu de mal avec l’extension du domaine des générateurs.
genre dict.keys() n’est plus une liste, mais un générateur. Du coup, si je modifie le dict, il faut faire :
for k in list(dict.keys())…
C’est vrai mais le cas où tu modifies le dictionnaire dans une boucle sur le dit dictionnaire est assez rare en Python. Généralement, soit tu boucles sur autre chose et du modifie le dico, soit tu créé une copie du dico (souvent avec une intension). Du coup ils ont optimisé pour le cas le plus courant : itérer dessus en lecture.
@julien, tu n’as pas besoin de transformer ton générateur en list dans pour la boucle for :
@mdbrlh Ce n’est pas ce que julien dit..
Il voulait dire que puisque la méthode ‘keys’ renvoie désormais un générateur et non plus une liste, une exception sera levée si tu modifies le dictionnaire à l’intérieur de la boucle.