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 frompour 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 cho7 (site web personnel) . Évalué à 3.
Ca commence à dater non ? :)
source : http://www.python.org/download/
[^] # Re: Moi toujours être bloqué en 2.7
Posté par claudex . Évalué à 5.
Il y a encore quelques gros trucs qui ne gèrent pas Python 3, comme Django par exemple.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Moi toujours être bloqué en 2.7
Posté par Nonolapéro . Évalué à 5.
Plus pour très longtemps puisque la dernière version alpha passe tous les tests. Désormais les développeurs écrivent pour Python 3 compatible avec Python 2.
Plus de détails par ici : https://www.djangoproject.com/weblog/2012/aug/19/experimental-python-3-support/
[^] # Re: Moi toujours être bloqué en 2.7
Posté par Maxime (site web personnel) . Évalué à 3.
matplotlib dans sa version stable n'est pas compatible Python 3, ça m'oblige à utiliser la version git pour ça.
Je suis confiant, dans 1 an la situation devrait largement s'améliorer.
[^] # Re: Moi toujours être bloqué en 2.7
Posté par claudex . Évalué à 5.
Il y a aussi le fait que seulement l'implémentation de référence implémente Python 3, Jython ou PyPy ne n'implémente pas encore.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Moi toujours être bloqué en 2.7
Posté par Maxime (site web personnel) . Évalué à 2.
Rah et à l'instant on me remonte que mon prog ne marche pas, il faut qu'il puisse tourner en 2.6. Heureusement pas des tonnes de changement, mais quand même, quand la version minimale utilisée par toutes les distros sera la 2.7, ça va faire du bien.
# très bien mais
Posté par palm123 (site web personnel) . É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 ?)
ウィズコロナ
[^] # Re: très bien mais
Posté par Larry Cow . Évalué à 5.
1
[^] # Re: très bien mais
Posté par neologix . É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 reno . Évalué à 4.
Pas grand chose, mais il vaut mieux écrire les nouvelles en Python 3.x.
[^] # Performances
Posté par Victor STINNER (site web personnel) . É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 Victor STINNER (site web personnel) . É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 benoar . Évalué à 5.
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.
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 Antoine . Évalué à 4.
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 benoar . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.