URL: https://linuxfr.org/news/python-3-4-est-sorti-avec-7-nouveaux-modules Title: Python 3.4 est sorti avec 7 nouveaux modules Authors: Victor STINNER Davy Defaud, Benoît Sibaud, Nils Ratusznik, BAud, NeoX, claudex, palm123, Nonolapéro, jihele, Philippe F et tuiu pol Date: 2014年03月17日T11:21:59+01:00 License: CC By-SA Tags: mongodb, lwn et postgresql Score: 75 En termes de nouveautés, Python 3.4 est la version de Python qui en apporte le plus ! Il n’y a pas moins de 7 nouveaux modules entre Python 3.4 et 3.3 (séparés de 18 mois), tandis qu’entre [Python 3.3](https://linuxfr.org/news/python-3-3-est-sorti) et [Python 2.7](https://linuxfr.org/news/python-27) (séparés de 27 mois) il y en a huit. En termes de propositions d’améliorations de Python, 14 PEP (_Python Enhancement Proposals_) ont été implémentées dans Python 3.4. Cette version donne un sérieux coup de vieux à Python 2.7. La 2^(e) partie de la dépêche détaille les principales nouveautés et la manière dont Python est développé. Mon article _Why should OpenStack move to Python 3 right now?_, cité ci‐dessous, explique pourquoi Python 2 est désuet et pourquoi vous devez porter dès maintenant vos applications sur Python 3. L’article a été écrit pour le projet OpenStack mais reste général. ---- [Python 3.4](https://www.python.org/download/releases/3.4.0/) [What’s New In Python 3.4](http://docs.python.org/3.4/whatsnew/3.4.html) [Why should OpenStack move to Python 3 right now?](http://techs.enovance.com/6521/openstack_python3) [LWN: New features in Python 3.4](https://lwn.net/Articles/585672/) [Historique des changements de Python 3.4](http://docs.python.org/3.4/whatsnew/changelog.html) ---- # Nouveautés de Python 3.4 # ## 7 nouveaux modules ## ### [asyncio](http://docs.python.org/dev/library/asyncio.html) : nouveau module de programmation asynchrone, [PEP 3156](http://www.python.org/dev/peps/pep-3156/) Le module asyncio est une boucle d’événements permettant de gérer des événements de types différents dans un unique [_thread_] ([processus léger](http://fr.wikipedia.org/wiki/Processus_l%C3%A9ger)) : [_sockets_](http://fr.wikipedia.org/wiki/Berkeley_sockets) (TCP, UDP, SSL), signaux UNIX, processus, primitives de synchronisation, etc. Bien que le cœur d’asyncio utilise des _callbacks_, la programmation se fait essentiellement avec des co‐routines. Une co‐routine est une fonction qui peut être mise en « pause » explicitement avec le mot clé `yield`. Pour être précis, asyncio utilise la nouvelle expression `yield from` de Python 3.3 qui est plus performante que `yield`. Le résultat de la co‐routine est renvoyé par un classique `return result` (autre nouveauté de Python 3.3, `return` ne pouvait pas être utilisé dans une co‐routine avant). Voici un exemple de « Hello World » asyncio utilisant une co‐routine : ```python import asyncio @asyncio.coroutine def greet_every_two_seconds(): while True: print('Hello World') yield from asyncio.sleep(2) # <~~ la magie opère ici loop = asyncio.get_event_loop() loop.run_until_complete(greet_every_two_seconds()) ``` Pour vous faire une idée de l’API choisie, je vous conseille de consulter la [documentation du module asyncio](http://docs.python.org/dev/library/asyncio.html) et notamment les exemples : * [« Hello World » par _callbacks_](http://docs.python.org/dev/library/asyncio-eventloop.html#example-hello-world-callback) ; * [« Hello World » avec des coroutines](http://docs.python.org/dev/library/asyncio-task.html#example-hello-world-coroutine) ; * [écho client en TCP](http://docs.python.org/dev/library/asyncio-protocol.html#echo-client) ; * [exemple de processus fils (sous‐processus)](http://docs.python.org/dev/library/asyncio-subprocess.html#example) ; * [exemple affichant les en‐têtes HTTP de l’URL passée en la ligne de commande](http://docs.python.org/dev/library/asyncio-stream.html#example). Pour une présentation plus générale et plus d’information, consultez la [liste des conférences sur asyncio](http://haypo-notes.readthedocs.org/asyncio.html#talks-about-asyncio). Pour mon travail chez eNovance, j’ai rétroporté asyncio pour Python 2 dans un nouveau projet appelé [Trollius](http://trollius.readthedocs.org/). La raison est que je souhaite remplacer _eventlet_ par Trollius dans le projet [OpenStack](http://www.openstack.org/) (en bref : un « petit » projet Python anodin de 2,5 millions de lignes, utilisé dans « le _cloud_ »), en partie [pour porter OpenStack sur Python 3](http://techs.enovance.com/6722/status-of-the-openstack-port-to-python-3-2). Mon article [_Use the new asyncio module and Trollius in OpenStack_](http://techs.enovance.com/6562/asyncio-openstack-python3) explique tout cela en détails. ### [ensurepip](http://docs.python.org/dev/library/ensurepip.html) Installeur du programme `pip` (et de ses dépendances), [PEP 453](http://www.python.org/dev/peps/pep-0453/). L’outil `pip` devient le gestionnaire de modules de référence pour Python. Le module `ensurepip` permet notamment d’installer `pip` lors de la création d’un nouvel environnement virtuel avec le module `venv`. Lire aussi [_Rationalizing Python packaging_](https://lwn.net/Articles/570471/) sur _LWN_. ### [enum](http://docs.python.org/dev/library/enum.html) : prise en charge des types d’énumération, [PEP 435](http://www.python.org/dev/peps/pep-0435/) Le module `enum` fournit une implémentation standard de types énumérés, permettant aux autres modules (tels que `socket`) de proposer des messages d’erreur plus explicites, et de faciliter le débogage en remplaçant les constantes opaques avec des valeurs énumérées rétro‐compatibles. Par exemple, `print(socket.socket().family)` donne `AddressFamily.AF_INET` au lieu de « 2 ». Ce nouveau module a fait l’objet d’un article [_An "enum" for Python 3_](https://lwn.net/Articles/551242/) sur le site _LWN_. ### [pathlib](http://docs.python.org/dev/library/pathlib.html) : API orientée objet de manipulation de chemins du système de fichiers, [PEP 428](http://www.python.org/dev/peps/pep-0428/) ### [selectors](http://docs.python.org/dev/library/selectors.html) : multiplexage d’entrées‐sorties haut niveau et efficace, basé sur les primitives du module `select`, fait parti de la [PEP 3156](http://www.python.org/dev/peps/pep-3156/) ### [statistics](http://docs.python.org/dev/library/statistics.html) : fonctions pour calculer des statistiques mathématiques de données numériques, [PEP 450](http://www.python.org/dev/peps/pep-0450/) ### [tracemalloc](http://docs.python.org/dev/library/tracemalloc.html) : tracer les allocations mémoires de Python, [PEP 454](http://www.python.org/dev/peps/pep-0454/) Il existe plusieurs outils pour calculer l’utilisation mémoire d’une application Python, dont notamment [Heapy](http://guppy-pe.sourceforge.net/), [Pympler](http://code.google.com/p/pympler/) et [Melia](https://pypi.python.org/pypi/meliae). Le principal défaut de ces outils est qu’ils groupent les allocations selon le type d’objet : quand la majorité de la mémoire est utilisée par des types très courants comme `str` ou `tuple`, il est très difficile de retrouver la partie du code comportant une fuite de mémoire. Le nouveau module `tracemalloc` prend le problème à l’envers. Plutôt que de partir des objets haut niveau (en parcourant les structures du ramasse‐miettes, module `gc`), `tracemalloc` se greffe sur l’allocateur mémoire bas niveau pour tracer les allocations mémoire de Python. `tracemalloc` utilise ensuite les structures de Python pour reconstituer la pile d’appel où l’allocation a eu lieu et l’associe au bloc mémoire alloué. Avec ces informations, `tracemalloc` permet de : * fournir la pile d’appel où un objet Python a été alloué ; * calculer des statistiques par fichier, par numéro de ligne ou par pile d’appel : taille totale, nombre et taille moyenne des blocs alloués ; * calculer la différence entre deux instantanés (_snapshots_) pour détecter des fuites mémoires. L’interface graphique `[tracemallocqt](https://bitbucket.org/haypo/tracemallocqt)` permet alors d’analyser finement ces données : filtrage, vue cumulative, groupage des allocations par fichier, ligne ou pile d’appel, comparaison deux instantanés, etc. Un paquet rétro‐porté est disponible pour Python 2.5-3.3 : [pytracemalloc](http://pytracemalloc.readthedocs.org/). Il nécessite en revanche l’application d’un correctif, puis de recompiler Python. Voir aussi la conférence que j’ai donnée à _Pycon FR 2013_ à Strasbourg sur `tracemalloc` : [support PDF](https://github.com/haypo/conf/blob/master/2013-PyconFR-Strasbourg/tracemalloc.pdf?raw=true) et [enregistrement vidéo](http://www.youtube.com/watch?v=oQ17KDBr24I). Je donne également une [conférence](https://us.pycon.org/2014/schedule/presentation/165/) le mois prochain à [_Pycon Montréal 2014_](https://us.pycon.org/2014/) sur le même sujet. ## Nouvelles fonctionnalités ## * Les fichiers et _sockets_ nouvellement créés sont marqués comme « non héritables » ([PEP 446](http://www.python.org/dev/peps/pep-0446/)) : ceci évite de passer des fichiers et _sockets_ aux processus fils, ce qui était la cause de nombreux problèmes et failles de sécurité listés dans la PEP. Ce changement peut casser la compatibilité ascendante, mais c’est un choix pour le bien de l’humanité : _« We are aware of the code breakage this is likely to cause, and doing it anyway for the good of mankind. »_ (extrait de la PEP). * Nouvelle option en ligne de commande `-I` _(isolate)_ pour lancer Python dans un mode isolé du système. * Amélioration de la gestion des _codecs_ qui ne sont pas des codages de texte (ex : `base64` et `rot13`). * Nouveau type `ModuleSpec` pour le système d’importation, [PEP 451](http://www.python.org/dev/peps/pep-0451/). * Le format de sérialisation `marshal` est plus compact et plus efficace. * La complétion des commandes par la touche de tabulation est maintenant activée par défaut dans l’interpréteur interactif. Par exemple, `pri` est remplacé par `print(`. ## Améliorations significatives de modules ## * _single‐dispatch_ générique pour les fonctions dans `functools`, [PEP 443](http://www.python.org/dev/peps/pep-0443/) ; * nouveau protocole (quatrième) de sérialisation pour le module `pickle` ([PEP 3154](http://www.python.org/dev/peps/pep-3154/)) : plus compact et permetant de sérialiser des objets qui ne pouvaient pas l’être avec Python 3.3 ; * le module `multiprocessing` a une nouvelle option pour éviter d’utiliser `os.fork()` sous UNIX (voir `multiprocessing.set_start_method()`) ; * le module `email` a un nouveau sous‐module `contentmanager` et une nouvelle sous‐classe de `Message` (`EmailMessage`) qui simplifient la gestion MIME ; * les modules `inspect` et `pydoc` sont désormais capables de faire de l’introspection de manière correcte sur une plus grande variété d’objets _« callables »_ (qu’on peut appeler, comme une fonction), ce qui améliore la sortie de la commande `help()` dans l’interpréteur interactif de Python ; * l’API du module `ipaddress` a été déclarée stable. ## Renforcement de la sécurité ## * Nouvelle fonction de hachage sûre utilisée par défaut, nommée [SipHash](https://131002.net/siphash/) ([PEP 456](http://www.python.org/dev/peps/pep-0456/)), dont on peut lire des détails dans [_Python adopts SipHash_](http://lwn.net/Articles/574761/) sur _LWN_ ; * les fichiers et _sockets_ nouvellement créés sont marqués comme « non héritables » (PEP 446) ; * nouvelle option en ligne de commande `-I` pour lancer Python dans un mode isolé du système ; * le module `multiprocessing` a une nouvelle option pour éviter d’utiliser `os.fork()` sous UNIX : les modes `spawn` et `forkserver` sont plus sûrs, car ils évitent de partager des données avec les processus fils. Sous Windows, les processus fils n’héritent plus de tous les _handles_ héritables du parent, uniquement ceux qui sont nécessaires ; * nouvelle fonction `hashlib.pbkdf2_hmac()`, offrant la 2^(e) fonction de dérivation de clé basée sur un mot de passe de PKCS#5 : [PBKDF2](http://en.wikipedia.org/wiki/PBKDF2) ; * prise en charge des versions 1.1 et 1.2 de [TLS](http://en.wikipedia.org/wiki/Transport_Layer_Security) par le module `ssl` ; * possibilité de récupérer les certificats depuis les dépôts de certificats Windows par le module `ssl` ; * le module `ssl` côté serveur gère maintenant [SNI (_Server Name Indication_)](http://en.wikipedia.org/wiki/Server_Name_Indication) ; * la classe `ssl.SSLContext` a été largement améliorée ; * tous les modules de la bibliothèque standard qui gèrent SSL prennent maintenant en compte la validation du certificat serveur, y compris la validation du nom d’hôte (`ssl.match_hostname()`) et la vérification de la [listes de révocation de certificats](http://fr.wikipedia.org/wiki/Liste_de_r%C3%A9vocation_de_certificats) (_Certificate Revocation Lists_, voir `ssl.SSLContext.load_verify_locations()`) : ceci veut dire que c’est maintenant possible en écrivant le code approprié, mais la validation demeure désactivée par défaut pour des raisons de compatibilité ascendante et de simplicité d’utilisation (_Cf._ [_Python, SSL/TLS certificates and default validation_](https://lwn.net/Articles/582065/) sur _LWN_). ## Amélioration de l’implémentation CPython ## * _Safe object finalization_ ([PEP 442](http://www.python.org/dev/peps/pep-0442/)) : les objets ayant un destructeur (méthode `__del__`) peuvent maintenant être détruits par le ramasse‐miettes quand ils font partie d’un cycle de référence (ensemble d’objets se référençant entre eux créant un cycle) ; * dans la plupart des cas, les variables globales d’un module ne sont plus mises à `None` à la fin de l’exécution de Python ; * les allocateurs mémoires sont désormais configurables, [PEP 445](http://www.python.org/dev/peps/pep-0445/) ; * _The Argument Clinic DSL_ ([PEP 436](http://www.python.org/dev/peps/pep-0436/)) offre une introspection complète des fonctions et méthodes implémentées en C. Seule une partie des fonctions C ont été converties vers _Argument Clinic_, le travail sera terminé dans Python 3.5. ## Autres changements ## Lisez _What’s New in Python 3.4_ (lien donné plus haut) pour voir la liste complète des nouveautés et changements de Python 3.4. # # Maturation de Python 3.4 # La maturation d’une nouvelle version majeure de Python prend de 18 à 20 mois. Pour Python 3.4, le développement a été programmé par la [PEP 429 : _Python 3.4 Release Schedule_](http://www.python.org/dev/peps/pep-0429/). Alors qu’initialement la date de sortie était prévue pour le 22 février 2014, il a été choisi de repousser la sortie pour corriger les bogues majeurs, plutôt que de publier une version boguée. Le _release manager_ de Python 3.4, Larry Hastings, a eu beaucoup de travail ces deux derniers mois pour canaliser les développeurs et focaliser le développement sur la correction de bogues. Comme d’habitude, l’ajout de nouvelles fonctionnalités était proscrit pendant deux mois dans la branche de développement principale (_« default »_). Entre la première version _release candidate_ et la version finale, Larry a choisi de créer une branche privée et de choisir quels _commits_ de la branche `default` méritaient ou non de faire partie de la future version finale. Ses choix ont été critiqués, mais Larry a tenu bon et a réussi à publier une nouvelle finale ! # Python Enhancement Proposals (PEP) # L’ajout d’un nouveau module, les changements touchant au cœur de Python et autres changements majeurs exigent d’écrire une PEP (_Python Enhancement Proposal_). Ce document sert de support pour discuter les changements et évite notamment qu’une discussion parte dans une boucle infinie (discussion qui repart régulièrement de zéro). Si des variantes sont proposées, elles doivent être notées dans la PEP, et si possible la PEP doit expliquer le choix de la solution proposée. Une PEP provoque souvent une bonne centaine de messages sur les listes de discussion `python-ideas` ou `python-dev`, voire plusieurs centaines dans les pires cas. L’auteur de la PEP doit alors tenter d’adresser chaque commentaire et compléter sa PEP au fur et à mesure. Le processus est usant, mais, _de mon expérience_, l’API après discussion est très largement supérieure à l’API initialement proposée. Discuter une PEP, document de quelques pages, est plus facile que de discuter le correctif de son implémentation (jusqu’à plusieurs milliers de lignes). Parfois, il y a deux solutions équivalentes qui présentent à peu près les mêmes avantages et inconvénients. Dans ce cas, le [BDFL (_Benevolent Dictator for Life_)](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life) (Guido van Rossum) doit trancher entre les deux solutions. Guido van Rossum peut déléguer son rôle s’il n’est pas disponible ou n’est pas intéressé par le sujet. Pour Python 3.4, les PEP `enum`, `pathlib` et `asyncio` ont provoqué des discussions enflammées avec plusieurs centaines de messages, mais le résultat est là : l’API a été éprouvée. Même si une PEP est refusée, le document en tant que tel devient _de facto_ la référence sur le sujet. Si quelqu’un redemande la même fonctionnalité, la PEP sert d’argumentaire pour expliquer le rejet de la fonctionnalité. Le processus de rédaction de la PEP garantit également que Python reste un langage cohérent et homogène. D’ailleurs, PHP a adopté un processus similaire depuis PHP 5.3 ([_PHP: Request for Comments_](https://wiki.php.net/rfc)). # Petite histoire de la création du module asyncio et du projet Tulip # Suite à une discussion intitulée « Quelle est la meilleure bibliothèque de programmation asynchrone en Python ? » sur la liste `python-ideas`, Guido van Rossum s’est mis dans la tête d’écrire la sienne (bah tiens, tant qu’à faire). S’en est suivi une discussion fleuve sur les bibliothèques existantes, sur les fonctionnalités attendues d’une telle bibliothèque, sur les _callbacks_ _versus_ co‐routines _versus_ Deferred (Twisted) _versus_ Future, etc. Cette discussion a donné lieu à une [PEP 3156 : _« Asynchronous IO Support Rebooted: the "asyncio" Module »_](http://legacy.python.org/dev/peps/pep-3156/), qui a mis plusieurs mois à être écrite. Une fois que les bases ont été mises en place, Guido s’est attaqué à une implémentation pour Python 3.3 sous le nom [Tulip](http://code.google.com/p/tulip/) (le nom du module Python étant `asyncio`). Les deux _frameworks_ majeurs étant Twisted et Tornado, il a repris la première lettre « T » et a choisi le nom Tulip : [référence à son pays d’origine](http://fr.wikipedia.org/wiki/Tulipe), les Pays‐Bas ? La PEP et l’implémentation ont bénéficié de critiques des auteurs des _frameworks_ existants qui ont permis des les améliorer. Les auteurs de Twisted auraient voulu une API plus proche de Twisted, mais Guido a volontairement choisi une API différente, notamment pour la syntaxe des co‐routines. # Rétroportages # Le développement de la plupart des nouveaux modules de Python 3.4 a débuté sur une version plus ancienne de Python. Des rétroportages sont disponibles pour les nouveaux modules : * `asyncio`, `selectors` : [_trollius_](http://trollius.readthedocs.org/) pour Python 2.6-3.3 ; * `enum` : [_enum34_](https://pypi.python.org/pypi/enum34) pour Python 2.4-3.3 ; * `pathlib` : [_pathlib_](https://pypi.python.org/pypi/pathlib) pour Python 2.7-3.3 ; * `statistics` : [_stats_](https://pypi.python.org/pypi/stats/) pour Python 3.1-3.3 ; * `tracemalloc` : [_pytracemalloc_](http://pytracemalloc.readthedocs.org/) pour Python 2.5-3.3. # Pour la suite # Le mois prochain aura lieu [_Pycon Montréal 2014_](https://us.pycon.org/2014/), rencontre mondiale Python regroupant plusieurs milliers de développeurs. Les nouveautés de Python 3.4 seront présentées, et les prochains développements seront discutés. J’espère que les efforts sur la programmation asynchrone Python vont se concentrer sur `asyncio`, et que de plus en plus de modules vont être compatibles. Il existe des _event loops asyncio_ pour _greenlet_, _gevent_, _libuv_, GLib, Tornado et 0MQ. Il existe des pilotes de base de données pour PostgreSQL, Redis, MongoDB et Memcached. Il existe des clients et serveurs HTTP, Web sockets, et un _worker_ Gunicorn. Voir la page [_asyncio third party_](http://code.google.com/p/tulip/wiki/ThirdParty) pour la liste complète, certains étant encore expérimentaux. Bien sûr, l’essentiel des évolutions de Python se fait dans des modules externes. Le [dépôt Python PyPI](https://pypi.python.org/pypi) comporte à l’heure actuelle 41 181 paquets.

AltStyle によって変換されたページ (->オリジナル) /