Journal Python 3.4 beta 1 est sortie

Posté par (page perso) . Licence CC by-sa
26
26
nov.
2013

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 :

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 (page perso) . Évalué à 1.

    Un 'tite typo dans le dernier paragraphe

    quand on utilise lancer des programmes (subprocess)

    :)

    • [^] # Re: typo

      Posté par (page perso) . É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 (page perso) . É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".

  • # Twisted

    Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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:

        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 (page perso) . É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 . Évalué à 2.

          https://twistedmatrix.com/trac/milestone/Python-3.x

          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 :-)

          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),

          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 (page perso) . Évalué à 2.

            Ceci dit j'ai arrêté de suivre Twisted depuis l'échec de mon fork :-)

            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 ?

            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 :-)

            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 . Évalué à 2.

              Pourquoi le fork à échoué ? Et pourquoi ne pas avoir directement proposé des patchs mainsteam ?

              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é).

              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.

              À 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 (page perso) . Évalué à 2.

                À vrai dire, s'il y a un remplaçant digne de ce nom, ça ne me dérangerait pas que Twisted perde en popularité.

                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.

                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.

                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 (page perso) . É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 (page perso) . É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 . Évalué à 7.

                  et hop une raison de plus d'utiliser git :)

                • [^] # Re: Twisted

                  Posté par . É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 (page perso) . É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 (page perso) . Évalué à 3.

                    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…

                    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.

                    Soit il y aura un projet concurrent, soit il y aura un fork, mais clairement ils vont rater un virage.

                    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 (page perso) . É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 (page perso) . É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 les bytes dans python3 sont capable de faire moins de chose que les str de 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 . É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 (page perso) . Évalué à 10.

      Cette release pue le frenchy à plein nez.

      Roquefort : fromage qui pue

      PEP 428, a "pathlib" module providing object-oriented filesystem paths
      PEP 442, improved semantics for object finalization: Safe object finalization
      

      écrite et implémentée par Antoine

      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 454, a new "tracemalloc" module for tracing Python memory allocations
      

      é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 ! :-)

      PEP 3154, a new and improved protocol for pickled objects: Pickle protocol version 4
      

      écrite par Antoine, implementée par Alexandre Vassalotti à l'occasion d'un Google Summer of Code.

      new "selectors" module: High-level I/O multiplexing (surcouche à select, poll, epoll, kqueue)
      

      écrite et implémentée par Charles-François

      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)
      

      é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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.