Journal Python 3.3.0 release candidate 2

Posté par .
Tags :
22
9
sept.
2012

Chers lecteurs,

La deuxième release candidate de Python 3.3 vient de sortir. Avec un peu de chance, ce sera aussi la dernière avant la sortie finale de cette nouvelle version stable.

Les améliorations de Python 3.3 sont nombreuses. Quelques exemples :

  • nouvelle syntaxe yield from pour déléguer un générateur à un autre
  • nouveaux modules lzma (compression xz et lzma), ipaddress (opérations sur adresses et masques IP), faulthandler (affichage d'une trace lors d'un plantage du processus)
  • intégration de pyvenv, outil équivalent au célèbre virtualenv
  • amélioration de la compacité des chaînes unicode et des dictionnaires d'attributs des objets

La liste complète des changements est très longue, je vous laisse la lire.

Afin d'éviter au maximum les régressions, nous invitons les utilisateurs de Python 3 à tester cette rc2 avec leurs applications.

Téléchargement (sources, installeurs Windows, binaires OS X) : http://www.python.org/download/releases/3.3.0/

  • # Moi toujours être bloqué en 2.7

    Posté par (page perso) . Évalué à 3.

    If you don't know which version to use, start with Python 2.7; more existing third party software is compatible with Python 2 than Python 3 right now.

    Ca commence à dater non ? :)

    source : http://www.python.org/download/

  • # très bien mais

    Posté par (page perso) . Évalué à 2.

    reste juste à convaincre le DSI que les applis en prod en Python 2.x qui tournent impec gagneraient à passer en Python 3.x (gagneraient quoi ?)

    If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

    • [^] # Re: très bien mais

      Posté par . Évalué à 5.

      (gagneraient quoi ?)

      1

    • [^] # Re: très bien mais

      Posté par . Évalué à 4.

      Pour le moment, les corrections sont appliquées à la branche 2.7, mais cela ne durera pas indéfiniment..

    • [^] # Re: très bien mais

      Posté par . Évalué à 4.

      Pas grand chose, mais il vaut mieux écrire les nouvelles en Python 3.x.

    • [^] # Performances

      Posté par (page perso) . Évalué à 3.

      Je pense que Python 3 distance de plus en plus Python 2 en terme de performance. Python 3.3 utilise par exemple moins de mémoire que Python 2.7 pour un projet Django (dumoins pour les chaînes de caractère) :
      http://www.python.org/dev/peps/pep-0393/#performance

      C'est les PEP 393 (str) et 412 (dict) qui ont aidé pour ça. Les codecs texte ASCII, Latin1 et UTF-8 sont beaucoup plus rapides dans Python 3.3 que dans 2.7.

      Python 3.2 a introduit un nouveau verrou global plus performant.

      Optimisions de Python 3.3, 3.2 et 3.1.
      http://docs.python.org/dev/whatsnew/3.3.html#optimizations
      http://docs.python.org/dev/whatsnew/3.2.html#optimizations
      http://docs.python.org/dev/whatsnew/3.1.html#optimizations

      À force d'optimiser le code ça et là, ça devient beaucoup plus rapide d'une manière globale. Si en plus ça utilise moins de mémoire…

    • [^] # Stabilité, threads, processus et asynchronisme

      Posté par (page perso) . Évalué à 2.

      Un thread ça va, c'est quand il y a en plusieurs qu'on a des problèmes.

      Gérer plusieurs threads et plusieurs processus est très compliqué. Python est de plus en plus stable au fil du temps, à force que des utilisateurs remontent des crashs sur des cas tordus. Il y a par exemple régulièrement des bugs remontés sur l'erreur EINTR qui n'est pas bien gérée par le module subprocess : à force de corriger cette erreur, ça devrait être bon à la fin :-) Les interactions entre threads et signaux sont aussi gérés de manière plus fiable. Python 3.2 ajoute un module concurrent.futures qui abstrait un peu plus la programmation concurrentielle.

      La programmation concurrentielle est également facilité par le support de timeout sur les verrous (ex: threading.Lock.acquire depuis Python 3.3) et les processus (ex: subprocess.Popen.communicate depuis Python 3.3).

      Tu peux sûrement te contenter de Python 2.7, mais ça te coûtera plus cher en temps de développement, et surtout en débogage je pense. (pour retomber sur des bugs déjà corrigés dans Python 3 ?)

  • # Bien

    Posté par . Évalué à 5.

    nouveaux modules […] ipaddress (opérations sur adresses et masques IP)

    Alléluia ! Enfin un module standard pour ça… Pourtant ça fait un bout de temps qu'il existe des modules non-officiels incompatibles entre eux et qu'on attendait une version standard.

    intégration de pyvenv, outil équivalent au célèbre virtualenv

    Là, au début, j'étais un peu sceptique là-dessus, connaissant la nature cradesque de virtualenv, et redoutant encore une autre solution incompatible. Au final, ça n'a pas l'air si mal que ça, même si ça ne corrige pas le problème de base (la cohérence des dépendances de différents softs et la stabilité des API).

    Mon seul regret est que ça n'arrivera pas dans wheezy du coup, ce qui ne va encore pas aider à faire accélérer la migration vers Python 3 en général (il y a plein d'autres raisons de migrer, hein, mais là ça en faisait deux sympas en plus).

    • [^] # Re: Bien

      Posté par . Évalué à 4.

      Là, au début, j'étais un peu sceptique là-dessus, connaissant la nature cradesque de virtualenv, et redoutant encore une autre solution incompatible.

      Justement, l'intérêt de l'intégrer à l'interpréteur, c'est d'éviter les hacks crades de virtualenv (là où virtualenv copie et patche la bibliothèque standard, pyvenv crée un fichier de config et quelques liens symboliques).

      • [^] # Re: Bien

        Posté par . Évalué à 3.

        Oui, j'ai vu ça. Mais s'ils avaient fait un truc vraiment incompatible, j'aurais eu peur que ceux qui doivent aussi « supporter » les versions < 3.3 ne s'y seraient pas mis à cause de ça.

Suivre le flux des commentaires

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