Python 3.4 vient de sortir, et avec cette release, je peux enfin recommander aux gens de se mettre à Python 3 plutôt que Python 2. Tout simplement parce que maintenant, en plus d’avoir énormément de libs qui ont migré, on a l’expérience de la bestiole. C’est stable, les perfs sont bonnes, la conversion de code d’une version à l’autre est bien documentée et maitrisée.
Et surtout, la 3.3 et la 3.4 viennent avec tout un tas des goodies super green.
Voici tout ce dont vous pouvez profiter avec Python 3 que vous ne pouvez pas faire avec Python 2.
Des classes classes
Les classes sont des new type classes en Python 3. Pas besoin d’hériter d’object:
# Au revoir ! class TouteMoche(object): pass # Bonjour ! class PropreEtNette: pass |
Les metaclasses ne se définissent plus comme un attribut spécial :
# Au revoir ! class TouteMoche(object): __metaclass__ = UnTruc # Bonjour ! class PropreEtNette(metaclass=Untruc): pass |
Super Super()
Franchement, qui se souvient de la syntaxe pour appeler proprement la méthode parente d’une classe ?
# Au revoir ! class FranchementHein(object): def __init__(self): super(FranchementHein, self).__init__() # Bonjour ! class FranchementHein: def __init__(self): super().__init__() |
Meta meta programmation
Le module inspect permet maintenant de récupérer des infos très très précises sur la signature des fonctions :
>>> from inspect import signature >>> def foo(a, *, b:int, **kwargs): ... pass >>> sig = signature(foo) >>> str(sig) '(a, *, b:int, **kwargs)' >>> str(sig.parameters['b']) 'b:int' >>> sig.parameters['b'].annotation <class 'int'> |
Et comme vous pouvez le voir, les annotations sont de la partie.
Les classes ont également un nouvel attribut __qualname__, qui, comme on peut s’y attendre, est le qualified name de la classe :
>>> class C: ... def f(): pass ... class D: ... def g(): pass ... >>> C.__qualname__ 'C' >>> C.f.__qualname__ 'C.f' >>> C.D.__qualname__ 'C.D' >>> C.D.g.__qualname__ 'C.D.g' |
Ca marche aussi pour les fonctions.
Enfin pour les gars qui sont vraiment tordus, on a une nouvelle méthode pour les metaclasses, __locallookup__, qui permet d’influencer le MRO à la volée.
Un yield qui yield
Bon, mon titre ne veut rien dire, c’était pour la continuité.
yield a maintenant un petit frère, yield from, qui permet de déléguer l’itération à un itérable sous jacent :
def generateur(): yield from "123" yield from (str(x) for x in range(4, 7)) yield from ("7", "8", "9") for i in generateur(): print(i) ## 1 ## 2 ## 3 ## 4 ## 5 ## 6 ## 7 ## 8 ## 9 |
Là ce n’est pas très utile, mais sur des générateurs complexes, c’est sympa. Surtout que yield from passe aussi les valeur avec send(), fait remonter les exceptions proprement et est détecté par les events loops du module asyncio, dont on parlera plus tard.
Batteries included, with charger
Pip et virtualenv sont livrés avec la 3.4 ! Rien de plus à faire, rien à installer ! Enfin !
Malheureusement pas virtualenv wrapper, mais c’est déjà pas mal.
Un nouveau format, le wheel, permet de faire des paquets binaires qui n’auront pas besoin d’être compilés sur la machine cible. Ca veut dire bientôt du numpy / scipy sans avoir à compiler quoi que ce soit. C’est un remplacement du egg plus simple et sans les problèmes de compatibilités. Il ne vise pas la distribution de projets Python standalones, comme le egg qui a notamment eu le problème de vouloir tout faire en même temps.
Pour ce dernier, le pyz est en discussion.
Enfin les scripts Python supportent maintenant l’équivalent du shebang, mais sous Windows. Ceci vient avec l’introduction de la commande py qui permet de lancer toutes les commandes Python (pip, venv, etc.) pour une version de Python installée spécifique.
Ah, non, pas “enfin”, j’ai oublié un truc :
python -X faulthandler votre_script.py vous permet maintenant d’obtenir une stacktrace sur les scripts utilisant ctypes \o/. Et le module tracemalloc permet d’enquêter sur l’allocation mémoire.
Tout un tas de trucs que les codeurs Java vont adorer
Il y a des Enums, et ça vient sous toutes les formes :
from enum import Enum, IntEnum # La version de feignasse : Animal = Enum('ant bee cat dog') # La version 'anal retentive' class Animal(IntEnum): ant = 1 bee = 2 # et tout ce qu'il faut entre les deux pour les centristes |
Pour les nostalgiques de l’overloading, on peut maintenant spécifier que le code d’une fonction est différent selon le type des arguments qui lui sont passés :
from functools import singledispatch @singledispatch def fun(arg): print('Comportement par défaut, teddy') @fun.register(int) def _(arg): print("Tu m'as passé un int, jonhy !") class Cacatoes: pass @fun.register(Cacatoes) def _(arg): print("Tu m'as passé un Cacatoes, billy !") fun('Do') fun([]) fun(1) fun(Cacatoes) ## Comportement par défaut, teddy ## Comportement par défaut, teddy ## Tu m'as passé un int, jonhy ! ## Tu m'as passé un Cacatoes, billy ! |
Et puis le module abc pour faire des classes abstraites, même si ça a été backporté en Python 2.7, donc un peu hors sujet.
Les built-in ont un peu changé
Pour le texte, c’est de l’unicode partout, avec utf8 par défaut pour les conversions. Ca veut dire plus de u devant les chaînes de caractère, plus de déclaration de l’encoding en haut des fichiers de code. Moins de decode / encode.
Mais ça veut dire aussi que open a besoin obligatoirement d’un paramètre encoding, dont la valeur par défaut est bien entendu utf8.
Attention cependant, le built-in bytes n’est pas l’exacte équivalent du type str en Python 2 puisqu’il ne possède plus certaines méthodes de manipulation de texte comme replace:
>>> "Trololo".replace('o', 'a') 'Tralala' >>> b"Trololo".replace('o', 'a') Traceback (most recent call last): File "<ipython-input-5-f7e93d6f629e>", line 1, in <module> b"Trololo".replace('o', 'a') TypeError: expected an object with the buffer interface |
C’est un peu chiant quand on manipule des protocoles binaires, et les mecs de mercurial ont un peu gueulé. Donc il est possible que ça change. J’ai mis beaucoup de fois le mot “peu” dans cet article, ce qui est stylistiquement très laid. Mais je suis trop paresseux pour éditer cet article qui fait maintenant 3 km.
Pour les nombres, on n’a plus à se soucier du type long, qui n’existe plus. / est maintenant la division ordinaire et // la division entière.
Pour les fonctions built-in, pas mal de changements avec bien entendu, print() qui devient une fonction, mais aussi toute ce qui est zip, map, etc, qui retournent des générateurs au lieu de listes, tout comme dict.items et consorts. Ah oui, et import est maintenant absolu par défaut.
Quelques libs en plus
Marre du module os ? pathlib permet de donner un petit goût d’objet à vos manipulations de FS, comme path.py. Ca reste moins bien, mais c’est mieux que rien.
Raz-le bol de recoder la fonction moyenne, médiane, etc ? Le module statistics a été ajouté pour ça.
Enfin, le fameux module mock, qui permet de simuler tout un tas de trucs sans tout casser :
>>> from mock import patch >>> with patch.object(os, 'listdir', return_value=['file2.txt', 'file2.text']): print(os.listdir('/etc/')) ... [u'file2.txt', u'file2.text'] >>> os.listdir('/etc/')[:2] [u'environment', u'hosts.allow'] |
Tout est bien rangé
Les fichiers bytecode Python sont maintenant tous groupés dans un dossier appelé __pycache__. Finis les .pyc qui trainent partout. Et en plus prefixés de l’architecture avec laquelle ils ont été générés. Toujours utile.
En prime pas mal de noms ont été normalisés : tous les modules sont maintenant en minuscule, tous les modules liés à IO sont groupés dans le module io, urllib 1 et 2 ont été mergés, et l’arborescence des exceptions pour les erreurs d’IO a maintenant beaucoup plus de sens :
# Au revoir ! from errno import ENOENT, EACCES, EPERM try: with open("document.txt") as f: content = f.read() except IOError as err: if err.errno == ENOENT: print("document.txt file is missing") elif err.errno in (EACCES, EPERM): print("You are not allowed to read document.txt") else: raise # Bonjour ! try: with open("document.txt") as f: content = f.read() except FileNotFoundError: print("document.txt file is missing") except PermissionError: print("You are not allowed to read document.txt") |
Asyncio, la prog asynchrone rebootée
Une des raisons pour laquelle je tape sur javascript aussi fort, c’est aussi la jalousie. Ils ont tous les derniers joujoux asynchrones hi-tech, meh !
Avec Python on était obligé d’installer tornado ou twisted pour ça, et c’était un peu dommage :)
Avec la 3.4, la prog asynchrone fait peau neauve (adieu l’horrible module asyncore) et propose de la prog asynchrone plus simple, plus légère, plus facilement intégrable : asyncio.
Si vous lisez ce PEP, ça ne va pas vous parler, alors je vais potasser tout ça et faire un petit article.
Mon seul regret avec asyncio, c’est que c’est un module uniquement bas niveau, alors que tulip, le prototype de la lib, contenait des mobiles haut niveau comme par exemple un client http bien foutu. Du coup ça a donné ce genre de discussion sur le blog, avec des gens qui ne comprenaient pas que je m’attendais à un peu de haut niveau et eux qui ne voyaient que le bas, et donc s’attardaient sur de la sémentique d’implémentation de la prog non blocante.
En conclusion
Le code Python 3 est plus court, plus cohérent, avec moins de surprises, moins de dépendances externes et plus de flexibilité. Des comportements par défaut sains un peu partout, des outils en plus, et comme d’habitude vous n’en utiliserez pas la moitié tellement il y a à faire.
Python 3.4 est vraiment un très bon cru, honnêtement, avec toutes ces améliorations, le langage parvient à se maintenir au niveau des petits jeunes et de leur hype, sans sacrifier sa solidité et sa cohérence.
C’est pour ça qu’on a attendu 5 ans. C’est pour ça que la migration a été lente et prudente.
Parce que la communauté Python fait vraiment les choses bien.
Les exemples du blogs seront donc à partir de maintenant en Python 3.
Et Django?
Django est compatible python 3 depuis la 1.5.
Petite erreur dans le lien vers le module tracemalloc, qui est un lien relatif et donc ne mène pas vers la bonne page.
Aussi, le lien vers la discussion asynchio mène vers une page admin, qui n’est donc pas lisible.
En première lecture, 3 erreurs :
Erreur dans l’exemple de l’overloading
fun(Cacatoes)devrait retourner :## Tu m'as passé un Cacatoes, billy !(si j’ai bien suivi. Sinon je veux bien une explication).Dans les built-in
Maid je suis trop paraisseux > Mais je suis trop paresseu
xEnfin Asyncio, le lien “ce genre de discussion” pointe sur l’admin (moi je veux bien aller voir mais j’ai pas les logs =D)
Petite erreur également. Le lien asyncore pointe sur sametmax.com
Et paramiko est aussi sorti en python3. Ce fut long.
Et pour que mon chiffre de 3 erreurs soit bon sans compter le doublon de entwanne, dans la partie Asyncio le lien vers “asyncore” pointe vers la racine du blog.
TRES très bon tout ça. Je pense que je vais m’y mettre aussi.
+1 pour super() juste incompréhensible en python 2.
Nice tout ça ! ^^
Quelques fautes dans “Asyncio, la prog asynchrone rebootée”, le lien vers “ce genre de discussion” redirige vers l’édition du commentaire souhaité. Et juste avant, “Avec Python ont été obligé d’installer tornado” => “Avec Python on était”, non ?
Dans “En conclusion”, “et comme d’habitude pour n’en utiliserait pas la moitié” => “vous n’en utiliserez”.
@François : bonne nouvelle !
@autres : merci, je corrige !
Et fatigué aussi : “Maid je suis trop paraisseux pour éditer cet article qui fait maintenant 3 km.”
un ‘s’ à ‘Mais’, et surtout : ‘paresseux’ :)
Merci pour cette synthèse en tout cas, je vais pouvoir prosel avec de vrais arguments ^^
@Anne Onyme Le probleme entre django et python 3 n’est pas django , mais les apps que tu vas installer qui elles, risques de ne pas etre compatibles python3 :)
Question quand même, pourquoi super garde ses parenthèses ?
Serait ce envisageable un “
super.” un peu comme le “base.” de C# ou le “parent::” de php ?Du coup je me répond tout seul je crois :
Quand la classe hérite de plusieurs autres classes, comment on lui indique la classe parente à utiliser ?
Un très bon résumé, pour les flemmards, c’est parfait, merci !
@Zanguu: oui tu te réponds tout seul. Super doit être une fonction pour attendre une classe en paramètre au besoin.
super() n’a pas vraiment changé en Python 3, c’est juste que interpréteur python le remplace automatiquement par super(NomClasse, self). C’est un simple search/replace :)
Du coup on peut mettre une classe parente à la place de NomClasse, et en fait, on peut même appeler super en dehors d’une classe.
Putain, moi qui hesitait entre Groovy et Python pour mon prochain language de script, ca va etre encore plus dur.
D’ailleurs, question : One te voit taper a droite (java script) et a gauche (Ruby), plus ou moins gentiment, mais jamais sur Groovy ? une raison ?
Groovy n’est pas vraiment un compétiteur : un mec qui aime Python peut faire du Python et du Java mélangé en utilisant jython, donc c’est un peu comme si il n’était pas sur le radar :)
Certes, mais pour un mec comme moi qui n’a pas d’opinion, t’en penses quoi en terme de feature ?
@ Teocali
C’est quoi Groovy ?
wikipedia l’explique mieux que moi
http://fr.wikipedia.org/wiki/Groovy_(langage)
Perso, le peu que j’ai teste (au sein de scripts gradle pour un gros projet) m’a beaucoup plus. Et comme je commence serieusement a me mettre serieusement a la prog Android et que gradle (un DSL base sur Groovy) est l’outil de build et de deploiement “officiel” pour android, j’avoue que je me tate.
@Teocali: ça rempli très bien son rôle de langage de scripting pour la plateforme java. C’est syntaxiquement assez agréable, mais ça manque d’outil comparé à la compétition et est limité à la JVM.
@herison: un langage de script pour la JVM.
Pour la prog mobile, Python est possible avec kivy, mais un langage plus proche de java aura toujours un avantage sur android.
Ce billet me rappelle que j’ai la chance de faire du Python 3 depuis 2 ans 1/2 à mon travail et j’ai donc découvert les subtilités de Python 2 après celle de Python 3 … Façon bienvenue à la préhistoire :3
Faudrait faire quelque chose pour règler votre cache. De plus en plus, je me fais servir la versin mobile du site….
@Sam : Pour la prog mobile, j’attends de voir. pour le moment y’a pas l’air d’avoir de projet serieux (Java ou pas, ce qui compte, c’est le bytecode et la JVM utilisee qui compte), mais ca ne saurait tarder, je pense, because gradle.
@gontran: on a précisé qu’on ne corrigerait pas ce bug. Faudrait faire une FAQ.
Moi, tant qu’il n’y a pas numpy, pyfits et matplotlib, ça ne me sert à rien et je reste calé sur 2.7…
Ben, les 3 fonctionnent sous python3… numpy et matplotlib je suis sûr, pyfits apparamment aussi : https://trac.assembla.com/pyfits/ticket/50.
Allez, au boulot !
C’est la joie la 3.4. Faut que je teste toutes les nouveautés!
Avec la version 3.4 on a bien le module asyncio, ok. Mais est-ce que le reste des modules est prêt à être utiliser de manière asynchrone ? Si non, je comprends pourquoi node.js a du succès.
Il y en a pas mal a migrer dans la lib standard. Mais on peut faire de l’asynchrone en Python avec twisted depuis bien avant que nodejs ait été créé, avec toutes les libs nécessaires (accès base de données notamment). Je dirais que le succès nodejs a été ailleurs, car son succès à commencé avant qu’il ait eu plein de libs.
Bonjour,
Il semblerait qu’il faille lire :
Au lieu de :
Bonne continuation.
Wat ?
J’ai écrit un petit article sur le module asyncio avec 2 exemples d’échange de données entre 2 coroutines. si cela peut aider à démarrer avec ce module…
http://www.hautefeuille.eu/asyncio-python.html
Bonjour,
Petite question à laquelle j’attends une petite réponse du coups :P
Peut-on créer une fonction et faire appel à une class à l’intérieur de celle-ci ? (la classe se trouvant dans un autre fichier que j’importe via un from fichier import class)
Et si oui (j’espère que c’est oui), comment peut-on procéder ainsi sans utiliser une méthode crade.
Je souhaite mettre chaque class/def dans des fichiers séparé pour alléger mon code, est-ce une bonne solution ?
Excusez-moi, si ça sort du thème :3
Quand ça sort du cadre de l’article tu peux toujours tenter ta chance sur http://indexerror.net ;)
D’accord, merci pour l’info ! ^^