La version 3.4 beta 1 de Python est sortie le 24 novembre 2013. Cette version marque le gel des nouvelles fonctionnalités de Python 3.4. Il est donc temps de vous faire saliver avec ce qui est à venir. Pas moins de 14 PEP ont été acceptées et implémentées et 7 nouveaux modules ont été ajoutés :
- PEP 428, a "pathlib" module providing object-oriented filesystem paths
- PEP 435, a standardized "enum" module
- PEP 436, a build enhancement that will help generate introspection information for builtins: The Argument Clinic DSL
- PEP 442, improved semantics for object finalization: Safe object finalization
- PEP 443, adding single-dispatch generic functions to the standard library: functools.singledispatch
- PEP 445, a new C API for implementing custom memory allocators: Add new APIs to customize Python memory allocators
- PEP 446, changing file descriptors to not be inherited by default in subprocesses: Make newly created file descriptors non-inheritable
- PEP 450, a new "statistics" module
- PEP 451, standardizing module metadata for Python's module import system: A ModuleSpec Type for the Import System
- PEP 453, a bundled installer for the pip package manager: ensurepip
- PEP 454, a new "tracemalloc" module for tracing Python memory allocations
- PEP 456, a new hash algorithm for Python strings and binary data: Secure and interchangeable hash algorithm
- PEP 3154, a new and improved protocol for pickled objects: Pickle protocol version 4
- new "selectors" module: High-level I/O multiplexing (surcouche à select, poll, epoll, kqueue)
- PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O: Asynchronous IO Support Rebooted: the "asyncio" Module, module aussi connu sous nom "Tulip" (version pour Python 3.3)
What’s New In Python 3.4 :
http://docs.python.org/3.4/whatsnew/3.4.html
Python 3.4 (beta 1), avec lien de téléchargement :
http://www.python.org/download/releases/3.4.0/
PEP 429: "Python 3.4 Release Schedule"
http://www.python.org/dev/peps/pep-0429/
La version 3.4 finale est prévue pour le 23 février 2014. En attendant, testez la béta avec vos applications favorites !
J'espère que asyncio va permettre d'unifier Twisted, Tornado, gevent, eventlet, gunicorn, etc. Et que de plus en plus de biliothèques vont être "compatible asyncio" pour pouvoir facilement faire de la programmation asynchrone sur n'importe quel type de connexion : signaux, processus, connexion à une base de données, serveur web, serveur UDP, etc. Pour moi, c'est la fonctionnalité qui tue de Python 3.4 !
Pour ma part, j'ai écrit les PEP 446 (non-inheritable files and sockets), 445 (malloc API) et 454 (tracemalloc). Les fichiers et sockets non héritables évitent de vilaines race condition et surtout des failles de sécurité quand on lance des programmes (subprocess), surtout quand on fait ça avec des threads. tracemalloc permet de facilement tracer les fuites mémoires.
# typo
Posté par kaliko (site web personnel) . Évalué à 1.
Un 'tite typo dans le dernier paragraphe
:)
[^] # Re: typo
Posté par Victor STINNER (site web personnel) . Évalué à 2.
En discutant, j'ai cliqué sur le bouton Envoyer au lieu de Prévisualiser, je n'ai pas eu le temps de finir ma relecture. J'ai vu la typo à posteriori, mais je ne vois pas comment éditer mon journal. Il va donc falloir que j'apprenne à vivre avec (soupir).
[^] # Re: typo
Posté par patrick_g (site web personnel) . Évalué à 3.
Nul besoin de vivre avec des regrets, c'est corrigé ;-)
Dis moi si c'est bien "lancer" que tu voulais garder et pas "utilise".
[^] # Re: typo
Posté par Victor STINNER (site web personnel) . Évalué à 2.
C'est bien comme ça, merci patrick.
# Twisted
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Ce serait déjà bien que Twisted finisse son passage à Python 3.
asyncio a été discuté sur la liste de diffusion de twisted: https://twistedmatrix.com/pipermail/twisted-python/2013-March/026700.html
[^] # Re: Twisted
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Les développeurs Twisted ne semblent pas intéressés par un portage sur Python 3, sinon ils l'auraient déjà fait. De plus, Antoine Pitrou a fait un fork non officiel qui tourne sous Python 3.
http://twistedmatrix.com/pipermail/twisted-python/2011-October/024649.html
Twisted est ancien (plus de 10 ans ?) et repose sur un système de callback. Le module asyncio reprend les bonnes idées de Twisted (ex: transport et protocole) en s'affranchissant de la syntaxe "callback" difficile à déboguer et à relire.
[^] # Re: Twisted
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Ils ont commencé le port depuis longtemps et la plupart des modules sont portés, ils cherchent à faire un port en faisant un code qui tourne à la fois sur python 2.7 et python 3, et ils ont une grosse batterie de tests pour valider ça. L'avancement peut être vu (si c'est à jour) à ces deux adresses:
https://twistedmatrix.com/trac/milestone/Python-3.x
https://twistedmatrix.com/trac/wiki/Plan/Python3
La syntaxe callback pose des problèmes à certains, personnellement je m'y suis fait et je n'ai pas tant de mal que ça à la débogguer (je la trouve même plutôt bien faite). Mais même s'il y a une API asynchrone qui arrive dans Python (qui a été faite en prenant en compte Twisted pour qu'il puisse l'intégrer si j'ai bien compris, tu en sauras sûrement plus que moi là dessus), ça n'apporte pas tous les protocoles supportés avec, avec les 11 ans d'expérience pour la gestions des subtilités, et les outils autour. Twisted est riche et mature, c'est une base solide.
En ce qui me concerne, c'est en particulier (mais pas seulement) la partie XMPP qui m'intéresse, et Ralph Meijer devrait remonter petit à petit Wokkel dans Twisted cette année.
Le fork semble tout à fait amical (je n'avais pas suivi ce fil je suis assez peu la liste de Twisted en ce moment), à lire en diagonale j'ai même l'impression qu'il va servir à porter le tronc principal.
[^] # Re: Twisted
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
À lire aussi sur le sujet, ce billet (qui a pas loin d'un an): http://labs.twistedmatrix.com/2013/01/twisted-python-3-and-you.html
[^] # Re: Twisted
Posté par Antoine . Évalué à 2.
Hmm… Déjà on voit que Twisted Core est loin d'être porté totalement, et je doute que les tickets soient exhaustifs (5 tickets pour Twisted Web, ça me semble peu). Ceci dit j'ai arrêté de suivre Twisted depuis l'échec de mon fork :-)
asyncio a été conçu pour que les principales bibliothèques d'I/O asynchrones pour Python puissent s'y adapter (Twisted, Tornado, gevent…). Ce n'est pas spécialement adapté à Twisted. La notion de protocole et de transport a été adoptée simplement parce qu'elle est assez pertinente :-)
[^] # Re: Twisted
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Ah oui, j'ai vu après coup que le message avait 2 ans. Pourquoi le fork à échoué ? Et pourquoi ne pas avoir directement proposé des patchs mainsteam ?
Je disais ça par rapport à ce genre de messages: l'API semble compatible, et Twisted devrait permettre à terme une compatibilité entre les deferred et les futures de Tulip. C'est vrai que ça serait super d'unifier un peu tout ça.
J'espère en tout cas que la multiplication des API asynchrones ne va pas provoquer un désintérêt pour Twisted, mais bon je ne m'inquiète pas trop surtout que le développement est toujours très actif.
[^] # Re: Twisted
Posté par Antoine . Évalué à 2.
Un peu pour les mêmes raisons, à savoir un manque chronique d'intérêt de la part des devs Twisted, voire une hostilité occasionnelle (cela se voit peut-être moins aujourd'hui, mais à une époque, notamment sur IRC, les devs Twisted étaient ouvertement hostiles à Python 3).
Le fork a réussi techniquement, à savoir que j'ai réussi à porter le coeur de Twisted vers Python 3 avec un effort relativement raisonnable. Mais vu la réaction des devs en face, cela n'avait pas d'intérêt de continuer.
Il faut savoir aussi qu'avant que je fasse ce fork, il y avait des tickets ouverts pour "nettoyer le code en vue du portage vers Python 3", mais la pratique recommandée était de proposer des petits patches ce qui, vu le boulot total requis, promettait d'être totalement ingérable (et, de facto, cette approche initiale a échoué).
À vrai dire, s'il y a un remplaçant digne de ce nom, ça ne me dérangerait pas que Twisted perde en popularité. Utiliser Twisted, c'est une expérience un peu particulière : ils ont leurs propres conventions de nommage, ils réinventent la roue sur beaucoup de sujets (par exemple ils utilisent leur propre système de logging largement inférieur à celui de la stdlib). Et quand tu contribues un patch ils sont capables d'ergoter sur des points de détails comme le nombre de retours chariot dans les définitions de classe.
[^] # Re: Twisted
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Ouai, enfin moi c'est au cœur de mon projet, et ça me ferait plus qu'un peu chier (je suis loin d'être le seul dans ce cas). Et je ne regrette pas du tout ce choix: Twisted m'a permis d'implémenter des idées très rapidement, les outils sont pratiques, et je trouve le tout relativement bien fait.
Les conventions de nommage, sauf erreur, c'est historique: c'était là avant la PEP 8 et ils ont gardé ensuite pour ne pas casser la compatibilité.
Pour le logging, il est parfaitement possible d'utiliser la stdlib: https://twistedmatrix.com/documents/current/core/howto/logging.html#auto3
Pour le reste c'est dommage.
[^] # Re: Twisted
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Ouai, enfin moi [Twisted] est au cœur de mon projet
Je doute que ça vaille la peine de porter les projets actuels de Twisted à asyncio. Le portage risque d'être long et risqué (en terme de régression).
Asyncio vise plutôt les nouveaux projets, ou bien les projets qui utilisent une boucle d'événement compatible (tout sauf Twisted?? :-p).
[^] # Re: Twisted
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Un peu pour les mêmes raisons, à savoir un manque chronique d'intérêt de la part des devs Twisted, voire une hostilité occasionnelle (cela se voit peut-être moins aujourd'hui, mais à une époque, notamment sur IRC, les devs Twisted étaient ouvertement hostiles à Python 3).
Pour information, j'ai fait deux tentatives de portage de Mercurial sur Python 3. Ma fork fonctionnait (dumoins avec les commandes simples). Mais pareil : vu la réaction très hostile, j'ai vite abandonné.
Le développeur principal semble carrément borné. Il est impossible de communiquer avec lui sur Unicode, il se bloque complètement. De mémoire, il m'a écrit un truc dans le genre "écoute, je suis développeur noyau, toi tu ne connais rien à UNIX, j'ai raison". Bon euh, j'ai quand même investi 3 années de ma vie à corriger des centaines de bugs Unicode dans Python 3, et je pense avoir quelques notions d'UNIX depuis le temps que je l'utilise (plus d'une dizaine d'années). J'ai proposé plusieurs solutions de transition (octets => Unicode) et des solutions pour que ça fonctionne avec Python 2 et 3. Je refuse de travailler avec des gens bornés et incapables de communiquer. J'ai passé mon chemin & basta.
[^] # Re: Twisted
Posté par Albert_ . Évalué à 7.
et hop une raison de plus d'utiliser git :)
[^] # Re: Twisted
Posté par Thomas Douillard . Évalué à 3.
Merci, je comprenais pas pourquoi il restait des trucs pas portés m'étant essayé à porter deux ou trois trucs simples sous python 3 sans aucun problème majeur, je comprend mieux.
[^] # Re: Twisted
Posté par flan (site web personnel) . Évalué à 1.
C'est quand même curieux de réagir comme cela, tout le monde est en train de passer à Python 3, ils n'ont strictement aucune chance que le reste du monde reste à Python 2 pour leurs beaux yeux…
Soit il y aura un projet concurrent, soit il y aura un fork, mais clairement ils vont rater un virage.
[^] # Re: Twisted
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Les problèmes que pourraient introduire le passage à Unicode sont listés dans la page suivante :
http://mercurial.selenic.com/wiki/EncodingStrategy
Je pense que cette page est pessimiste, les problèmes peuvent être résolus l'un après l'autre, et pas tous d'un coup.
Le projet Mercurial est très actif, maintenir un fork serait très chronophage. Il faut que la transition à Python 3 soit progressive et soit faite upstream.
[^] # Re: Twisted
Posté par flan (site web personnel) . Évalué à 2.
Dans ce cas, le projet concurrent risque bien d'être git.
Déjà que github doit faire beaucoup de mal à tous les concurrents de git (quasiment à chaque fois que je vois un projet sur Google Code, soit il a déménagé sur Github, soit il est mort), si en plus ils restent sur une techno (Python 2) de plus en plus vue comme obsolète, ça risque d'être douloureux…
[^] # Re: Twisted
Posté par marmoute (site web personnel) . Évalué à 2.
Il y a deux obstacles principaux au portage de Mercurial vers python3.
Le premier est lié au changement (
str,unicode) → (bytes,str). Mercurial manipule principalement des bytes (le contenu d'un fichier sont des bytes, les noms de fichiers sont des bytes, les protocoles réseaux s'échangent des bytes). Hors lesbytesdans python3 sont capable de faire moins de chose que lesstrde python2. Le googler qui s’intéresse au port de Mercurial vers python 3 discute avec d'autres développeur Python pour arranger ça.Le second est un problème de performance. Python 3 est sensiblement plus lent, en particulier à démarrer (et pour l'import de module il me semble) ce qui est critique pour Mercurial qui est processus avec des temps de vie cours. Encore un fois Il me semble que des développeurs python tentent d'améliorer ça.
Aucun de ces deux problèmes ne correspond à ce pourquoi Victor c'est fâché avec Matt Mackall ;-)
# Un entretien avec les développeurs francophone de Python — épisode 2
Posté par Nonolapéro . Évalué à 3.
Puisque, au moins, trois francophones (Victor Stinner, Antoine Pitrou et Charles-François Natali) ont activement participé au développement de cette nouvelle version, ça serait une bonne occasion de réitérer un entretien comme celui d'avril 2010. Reste à savoir s'ils sont intéressés pour répondre aux diverses questions des moules du coin_/.
[^] # Re: Un entretien avec les développeurs francophone de Python — épisode 2
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Cette release pue le frenchy à plein nez.
écrite et implémentée par Antoine
écrites et implémentées par moi-même, la PEP 445 a été validée par Antoine, la PEP 454 validée par Charles-François. Je vous rassure, ils ont été super chiant, quand on écrit une PEP, les amis ne comptent plus ! :-)
écrite par Antoine, implementée par Alexandre Vassalotti à l'occasion d'un Google Summer of Code.
écrite et implémentée par Charles-François
écrite par Guido van Rossum, implementé par Guido mais avec un grand nombre de contributeurs, validée par Antoine
Ça fait presque 40% des nouveautés majeures faites uniquement par les français, et les français sont impliqués dans 50% des nouveautés majeures. D'ici Python 3.5 voir Python 3.6, on a prévu de traduire les mots clés en français, puis de mettre du fromage dans la stdlib.
[^] # Re: Un entretien avec les développeurs francophone de Python — épisode 2
Posté par serge_sans_paille (site web personnel) . Évalué à 1.
J'ai ri :-)
[^] # Re: Un entretien avec les développeurs francophone de Python — épisode 2
Posté par windu.2b . Évalué à 1.
Et de renommer le langage en Winthon ? Ou en PyDev ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.