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:
passLes metaclasses ne se définissent plus comme un attribut spécial :
# Au revoir !
class TouteMoche(object):
__metaclass__ = UnTruc
# Bonjour !
class PropreEtNette(metaclass=Untruc):
passSuper 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
## 9Là 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 centristesPour 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 interfaceC’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.
