Python 3.0, qu'en pensez-vous ?

La version finale de Python 3.0 devrait bientôt sortir (actuellement la rc3).

Cette version va rompre la compatibilité avec Python 2.x (même si la migration de vos programmes ne devraient pas être trop difficile, l'outil 2to3 devrait de ce côté pas mal aider).

On peut noter:
- print devient une fonction. Il vous faudra donc utiliser les ()
- Unification des types str et unicode. Les questions récurrentes sur les problèmes d'encodage devraient moins se faire sentir. En contre-partie, un type byte est créé.
- des fonctions qui retournaient auparavant des listes retourneront maintenant des iterateurs ou des vues (range, map, filter, ...). Il vous faudra caster explicitement si vous voulez tout de même récupérer des listes.
- La division / retournera un float même sur des entiers
- Pas mal de fonctions/modules devenues obsolètes sont supprimés de la distribution standard.
A noter que pour le moment Python 3.0 que ces prédécesseurs
Vous pourrez retrouver tous les changements ici: http://docs.python.org/dev/3.0/whatsnew/3.0.html


Qu'est-ce qui vous plait dans les changements apportés par cette version ?
Allez-vous vous mettre rapidement à Python 3.0 ? Il faudra tout de même patienter un peu avant de voir la migration des différentes bibliothèques tierces utiles.

What's new : http://docs.python.org/dev/3.0/whatsnew/3.0.html
Téléchargement : http://www.python.org/download/releases/3.0/
Documentation : http://docs.python.org/dev/3.0/

Moi j'avais entendu parler de typage statique optionnel mais je n'ai pas vraiment regardé les details mais ça peut etre pas mal (surtout si le polymorphisme suit) à la fois pour le travail colaboratif (pas toujours facil de savoir ce qui se balade quand c'est pas son propre code) et les IDE (vérification des arguments à l'écriture).

Sinon l'apparition du type byte, l'unicode en string de base, ...

Enfin bon on vera ... ;)

Première des choses, il n'y a pas de typage statique. Il y a des annotations, mais le compilateur ne s'en sert pas, c'est pour les programmeurs et pour la documentation.

Pour ce qui est de Python 3.0, je le trouve très bien. C'est pas vraiment différent de Python 2.x (contrairement à Perl 5 vs Perl 6), mais certains changements font du bien:

• L'intégration du Unicode. Les problèmes d'encodings sont tellement chiant, j'ai super hâte que tout le monde se mette à utiliser Unicode et je suis bien content que Python l'utilise par défaut
  
• La plupart des fonctions qui retournaient des listes retournent maintenant des itérateurs (range, keys, values, items, etc.)
  
• Même si c'est certain que je vais avoir énormément d'erreurs de syntaxe à cause de ça, faire que print soit une fonction est un point positif.
  
• Plus de classic classes
  
• Enfin de vraies divisions. 3 / 2 retourne 1.5 et 3 // 2 retourne 1 (ancien comportement)

J'ai lu un article d'un programmeur qui a converti feedparser avec l'outil 2to3. Apparament ça fonctionne bien.

hummmm...

t a un site avec un exemple de code de typage euhhh "définie" en python 3 ? :)

Code:

---

1 2 3 4 5 6 7 8 9

>>> def plus(a: int, b: int) -> int: ... return a + b ... >>> plus(10, 20) 30 >>> plus.__annotations__ {'a': <type 'int'>, 'b': <type 'int'>, 'return': <type 'int'>} >>>

---

hummm je suis pas super fan de la syntaxe (horreur des "->" dans les langages on avait été epargné jusqu'ici :mouarf:)

oki merci pour l'info :)

Citation:

---

Envoyé par anthyme

hummm je suis pas super fan de la syntaxe (horreur des "->" dans les langages on avait été epargné jusqu'ici :mouarf:)

oki merci pour l'info :)

---

Effectivement, j'aime pas non plus la syntaxe pour le return, mais enfin. Une chose le fun par contre, les IDEs vont pouvoir donner plus d'informations, mais sans qu'on perde le typage dynamique.

Je dois mentionner aussi que les annotations ne doivent pas obligatoirement être des types:

Code:

---

1 2 3 4 5 6 7

>>> def foo(x: 'entier positif') -> 'brosse a dents': ... pass ... >>> foo.__annotations__ {'x': 'entier positif', 'return': 'brosse a dents'} >>>

---

Ce sont vraiment juste des annotations, des infos supplémentaires qu'on peut donner aux paramètres.

La Release 3.0 est maintenant disponible : http://www.python.org/download/releases/3.0/

Arf toujours pas de join sur les tuples/arrays, pourquoi ils font pas comme dans tout les langages au lieu de mettre ca sur str ? :/

Citation:

---

A noter que pour le moment Python 3.0 que ces prédécesseurs

---

-> Pourriez-vous rajouter les mots manquants ?

Nouveau en python je vais directement me lancer sur Python 3000. En comparaison avec la v2 l'unicode, le multiprocessing et l'amélioration des classes I/O et les types strings/datas font la différence : programmation système, applis en réseaux, supervision ... ;)

Citation:

---

Envoyé par kedare

Arf toujours pas de join sur les tuples/arrays, pourquoi ils font pas comme dans tout les langages au lieu de mettre ca sur str ? :/

---

Je ne trouve pas ça surprenant, c'est bien dans la philosophie Python, donc ça me va ;)

Hello,
je n'ai découvert Python que depuis 3 semaines :roll: Je connais en fait (un peu le C) avec lequel je fais mes petits programmes d'amateur du dimanche. Je trouve dommage que les développeurs de Python portent leurs efforts sur cette version 3.0, la 2.5 me paraissant pas mal :lol: Par contre, je trouve que certains points mériteraient une bonne amélioration. Entre autre , je pense surtout au déploiement. Une vraie cata ! Mon début de programme tarot sous wxpython finit avec une bonne quinzaine de dll et divers fichiers pour près de 12 Mo :aie:
Je n'ai pas trouvé de déploiement en statique et c'est très dommageable. Je trouve de plus qu'un compilateur optimisant la vitesse aurait été bien venu ;) Le python se révèle très mais alors très lent comparé au C. Je m'y attendais mais pas à ce point là (facteur 100 ?). Bref, un petit compilateur me produisant un seul .exe avec les libs en statique et un code plus rapide m'aurait nettement plus intéressé :king: Ceci n'est l'avis que d'un amateur :mrgreen:

François

Citation:

---

Envoyé par vega95

Le python se révèle très mais alors très lent comparé au C. Je m'y attendais mais pas à ce point là (facteur 100 ?).

---

C'est surtout qu'on ne fait pas les mêmes choses en C qu'en Python ;) De mon côté, je n'ai pas de telles différences de vitesse entre mes codes :)

Et si tu veux compiler, tu peux en partie -> Cython ;). Mais tu perds certains avantages de Python. On ne peux pas avoir le beurre et l'argent du beurre.

Pour le compilateur, il y a des utilitaires, comme py2exe, bbfreeze, ... Et pour le code plus rapide, il faudra attendre Pypy ou basculer sur IronPython ou Jython.

Je ne connaissais pas PyPy 8-) Voilà typiquement un projet qui m'intéresse plus que la v 3.0 ;)

Citation:

---

Le python se révèle très mais alors très lent comparé au C.

---

Python est certainement un peu plus lent que du C, c'est normal puisque Python est basé sur C. Maintenant pour rendre un programme python rapide il faut commencer par se remettre en question soit même en optimisant l'ecriture de son code, et en traquant les mauvaises ecriture (bien souvent hérité de pratique de programmation en C/C++)
Python demande au développeur d'être rigoureux et méthodique si il veut un programme performant.
Personnellement je commercialise un serveur de traitement d'images ecrit en Python. En comparant, les perf de mon serveur avec des concurrents ecrit en language compilé tel le C, je suis aussi rapide voir plus rapide dans certaines conditions.
Donc la remarque que python est lent, n'est pas trés pertinente en soit.
Amitié

En ce qui me concerne j'utilise python depuis environ 1 an et je suis toujours rester sur la version 2.5 que je trouve vraiment bien.

Certains points me paraissent pas mal sur la version 3.0 et d'autres moins... il faudra que je me fasse une idée en l'utilisant.

Je me demande d'ailleurs s'il est possible de garder la version 2.5 pour continuer à coder avec tout en installant sur le même PC la version 3.0 pour l'essayer, ou faut-il utiliser un autre PC?

Citation:

---

Envoyé par Jiyuu

Je me demande d'ailleurs s'il est possible de garder la version 2.5 pour continuer à coder avec tout en installant sur le même PC la version 3.0 pour l'essayer, ou faut-il utiliser un autre PC?

---

On peut parfaitement installer 2 versions de Python sur le même système; le répertoire par défaut contient d'ailleurs le numéro de version (Python25, Python30). A l'installation de Python 3.0, il faut simplement choisir si tu veux associer les extensions (.py, .pyw, ...) avec la nouvelle version ou l'ancienne (sous Windows en tout cas). Mais rien n'empêche par après de lancer un .py avec l'une ou l'autre version.

Citation:

---

Envoyé par Jiyuu

En ce qui me concerne j'utilise python depuis environ 1 an et je suis toujours rester sur la version 2.5 que je trouve vraiment bien.

Certains points me paraissent pas mal sur la version 3.0 et d'autres moins... il faudra que je me fasse une idée en l'utilisant.

---

Je développe toujours en Python 2.5 au boulot et en Python 2.6 chez moi. C'est un peu obligatoire car les bibliothèques que j'utilise ne sont pas encore disponible pour Python 3. Ca viendra.

Je pense que nous sommes beaucoup dans ce cas.
Il ne faut pas perdre de vue que Python 3 est l'avenir de Python et qu'un jour, le choix ce fera de lui même, alors, dès que possible, il faudra bien utiliser Python 3. Rester sur Python 2 (déjà une vielle version) sans nécéssité est une abération, enfin je pense, ou alors il faut changer de langage, car Python 2 ne sera plus utiliser. Donc, la question n'est pas de savoir si l'on passe ou non à Python 3, mais quand y passer.

Citation:

---

Envoyé par Gamal le Celte

Je développe toujours en Python 2.5 au boulot et en Python 2.6 chez moi. C'est un peu obligatoire car les bibliothèques que j'utilise ne sont pas encore disponible pour Python 3. Ca viendra.

Je pense que nous sommes beaucoup dans ce cas.
Il ne faut pas perdre de vue que Python 3 est l'avenir de Python et qu'un jour, le choix ce fera de lui même, alors, dès que possible, il faudra bien utiliser Python 3. Rester sur Python 2 (déjà une vielle version) sans nécéssité est une abération, enfin je pense, ou alors il faut changer de langage, car Python 2 ne sera plus utiliser. Donc, la question n'est pas de savoir si l'on passe ou non à Python 3, mais quand y passer.

---

Je suis entièrement d'accord avec toi. En fait actuellement j'utilise wxPython et à ma connaissance il n'est pas encore sorti pour Python 3.0
Je ne voyait donc pas l'intérêt de migrer tout de suite.

Ce pendant comme il est possible d'installer deux versions de python sur le même PC sans risque je vais m'y lancer.
D'ailleurs l'astuce de dividee est bien et je n'y avais pas du tout pensé. Je pense donc utiliser par exemple python 2.5 pour tout les extensions .py (comme aujourd'hui) et python 3.0 pour .pyw

Cela me permettra d'utiliser les deux versions.

Merci et bonne soirée

Un débutant aura pour le moment tout intérêt à commencer avec Python 2.6 pour pouvoir profiter des bibliothèques tierces qui sont tout de même indispensables pour profiter pleinement des possibilités de Python.
Pour ma part, dès que NumPy sera disponible en 2.6, je passerai au boulot avec cette version (tous les binaires des autres bibliothèques que j'utilise existant maintenant)
Mais il peut déjà être bien de commencer à avoir en tête les changements qu'apportera Python 3, cela peut déjà faciliter une migration future (qui n'aura lieu de toute façon pas avant un bout de temps) en évitant les modules ou fonctions dépréciées entre autres

Pour moi, le changement qui m'apparaît le plus important est la gestion par défaut de l'unicode (c'est surtout que l'ascii 7 bits utilisé par défaut dans Python 2 apporte pas mal de galère (alors qu'un ascii 8 bits aurait été largement suffisant)) ainsi que la différence des divisions / et // , ce qui allégera mes codes en évitant à avoir à forcer le cast en float des nombres.

J'ai installé la 3.0 par curiosité, mais je resterais encore avec la 2.5 un bon moment (ou la 2.6, le jour où je n'aurais pas la flemme de réinstaller les librairies que j'utilise). Passer à la 3.0 pour le moment, c'est se priver de presque toutes les librairies externes, qui font aussi la force de Python.

Quant aux nouveautés de la version 3, j'en suis plutôt content en général, sauf pour la division. Je sais que c'est annoncé depuis longtemps, mais cela va à contre-courant de tous les autres langages que je connais, et je suis certain de souvent oublier d'utiliser // au lieu de /. L'erreur peut être difficile à détecter car elle peut ne se manifester que rarement:

Code:

---

1 2 3 4

>>> 3**10 / 3 == 3**9 True >>> 3**100 / 3 == 3**99 False

---

C'est quand-même pas si difficile de caster un int en float si on veut une division réelle.

Je suis particulièrement content pour l'Unicode, qui est malheureusement un vrai casse-tête quelque fois en Python 2, ainsi que pour les "views" et les itérateurs. La plupart du temps, xrange() ou dict.iteritems() sont plus efficaces que range() et dict.items() (pour n'en citer que 2), mais leur nom n'est pas idéal et elles sont de ce fait souvent ignorées par les débutants. Idem pour l'utilisation automatique des packages optimisés s'ils sont disponibles (cPickle, etc.)

Je regrette un peu la disparition de reduce() des builtins; alors que map() ou filter() peuvent être avantageusement remplacés par une compréhension de liste, ce n'est pas le cas de reduce(). Mais bon, j'en ferais pas une maladie (elle est toujours dans la librairie standard, tout de même).

Citation:

---

Envoyé par airod

en traquant les mauvaises ecriture (bien souvent hérité de pratique de programmation en C/C++)
Python demande au développeur d'être rigoureux et méthodique si il veut un programme performant.

---

Qu'est-ce qu'il ne faut pas entendre 8O ! Je ne connais pas le python, mais connaitre le C avec rigueur (au standard C99) apporte bien au contraire d'excellentes méthodes de programmation.

Le C, pour qui le maîtrise, demande beaucoup plus de rigueur que le python et autres languages comme le VB.

Le débat sur les performances entre le C et le Python est biaisé. Le python est basé sur le C et est à la base un language script. Le C laisse loin dérrière le python.

J'ajouterais que quelque soit le language si tu veux pondre un code pourri rien ne t'en empêche.

Bonjour.
Moi j'utilise Python depuis pas longtemps et je n'avais jamais programmé avant.
Je trouve que l'idée de l'unicode est la meilleur chose que Python3 offre car mes logiciels en konsole plantent souvant au niveau de l'affichage...
Par contre je trouve hiper nul l'idée de briser la compatibilitée. Cela veut dire que des milliers de codes (ceux du site notemment) douvent être réécrits pour Python3 et c'est pas ce qu'il y a de plus cool de réécrire une partie du code parce qu'on a mit plain de print et qu'il faut les rechercher apres.
De plus il y a eut certains changement mais les explications complètes sont en anglais (J'arrive pas a importer un fichier dans le même repertoir que mon code avec "from nomdudocument import *" et ca c'est galère.
De plus a ce que je comprend il n'y a pas beaucoups de bibliotheque compatible alors qu'il aurais fallut (ou il faudrais faire à l'avenir) une version complète de python avec toutes les bibliotheques (histoire de simplifier l'installation de celui qui ne crée pas de logiciels mais qui en execute. Ils font bien ça avec Java Runtime Environnement)
Non frenchement Python3 c'est bien mais pas pour tout de suite. Je l'ai installé sur mon ordi mais j'attendrais un mois ou deux pour avoir la documentation adapté à cette version.
Sinon il y a des bonnes idées la-dedans mais bon faut être patient.
Au revoir à tous et bon scripts sur python (2.5, 2.6 ou 3)
PS: Est-ce que Python3 est plus accessible (Synthèse vocal NVDA ou autre, zoom...) Parce que les interfaces graphiques en Tkinter ne sont pas lu vocalement et du coups cela prive certains. Moi qui veut faire des programmes utilisables par tout le monde je trouvais ça regrétable dans Python2.5 alors est-ce que Python3 fonctionne bien la-dessus?

Tout d'abord, il y a un script de conversion de la version 2.6 vers la 3, donc normalement cette partie est couverte. Sauf pour les modules utilisant des extensions C. Pour eux, il faudra attendre un petit peu plus longtemps.

Citation:

---

De plus a ce que je comprend il n'y a pas beaucoups de bibliotheque compatible alors qu'il aurais fallut (ou il faudrais faire à l'avenir) une version complète de python avec toutes les bibliotheques

---

Impossible ! Ca voudrait dire qu'il faut attendre 4-5 ans avant de sortir une version avec tous les modules à jour, et encore un grand nombre ne serait plus maintenu entre temps, sans compter que 4-5 ans sur un projet, sans release, ça va à l'encontre de l'Open Source d'un certain sens.
Là, les projets les plus simples et/ou les plus fondamentaux peuvent franchir le cap (je pense aux projets sans extension C, ou à Numpy sur lequel est basé un très grand nombre d'autres projets). Puis une nouvelle itération verra la transition des modules basés sur les précédents, ...

Et il existe, au moins dans le milieu scientifique, deux distributions plus ou moins complètes de Python (Python(x,y) et ETS).

Bonjour

Pour ma part, je suis déjà complètement passé à Python 3.0. Facile, je n'ai pas aujourd'hui une base énorme de code Python, cela risque de changer très vite.

La rupture de compatibilité ne me gène pas, au contraire, je trouve cela plutôt bien car cela va bien dans le sens d'un langage globalement plus propre. Et c'est bien pour cela que j'aime le python, c'est à mon sens l'un des langages qui permet une écriture de code très rapide et assez propre.

Par contre, j'ai lu l'exemple de la telnetlib en version 2.5 et 3.0, je trouve que la gestion généralisée de l'unicode ne rend pas toujours certains détails facile à comprendre. Si je n'avais pas déjà eu des problèmes de traduction et représentation de certain alphabet, je trouverais cela un peu lourd.

Emmanuel

Mon avis personnel sur la question est que je suis plutôt content de ce que j'ai pu lire sur les changements fait pour la 3.0.

Le point qui a controverse étant forcément la backward compatibilité du langage. Il y a beaucoup de langages qui trainent des verrues et des absurdités dans leurs standards pour la seule et unique raison qu'il faut être absolument backward compatible. Très honnêtement, je ne suis pas sur que garder un bug de spécification pendant 15ans soit d'une quelconque utilité.
A un moment il faut aller de l'avant et couper avec certaines choses aberrantes.


Donc avis très favorable de mon coté. Maintenant je ne compte pas passer de suite en 3.0. Je vais laisser murir la version, laisser arriver les corrections de bugs et la traduction des librairies et ensuite je passerais en 3.0.

Bonjour,

Je voulais juste vous informer que le magasine "GNU/Linux Magazine / France" venais de sortir un Hors Série en Janvier/Février entièrement consacré à python...

"Explorez les richesses du langage Python"...

il contient notamment tout un article sur Python 3.0...

Citation:

---

Envoyé par vega95

Mon début de programme tarot sous wxpython finit avec une bonne quinzaine de dll et divers fichiers pour près de 12 Mo :aie:

---

Recompresse Library.zip avec p7zip au maximum, et compresse tout les dll/exe via UPX, ca devrais pas dépasser les 5mo

Alors moi ce qui m'embête le plus dans cette nouvelle mouture, c'est la nouvelle syntaxe du string format.

Je préférais carrément l'usage du %

print "Salut %s" % nom
devient
print("Salut {0}".format(nom))

Pour le coup, non seulement c'est plus verbeux, mais en plus les brackets ({ et }) c'est trop relou à tapper comparé à un %, je perd grave en productivité !


A part ça le reste ne me dérange pas trop. J'en ai profité pour découvrir les décorateurs, que j'avais un peu laissé de coté jusqu'à maintenant même si ça existe depuis un bail... C'est plutôt sympa, du sucre syntaxique comme disent certains, mais c'est sympa :)


Bref, s'il pouvait remettre juste l'ancienne syntaxe de string formatter en rétro compatibilité pour les faignants comme moi, ce serait sympa :D

Citation:

---

Envoyé par cho7

Bref, s'il pouvait remettre juste l'ancienne syntaxe de string formatter en rétro compatibilité pour les faignants comme moi, ce serait sympa :D

---

Il est toujours possible, avec Python 3.0, d'utiliser l'ancienne syntaxe pour le formatage des chaines de caractères.

Thierry

En fait, je n'ai pas compris pourquoi cette modification des strings formatter était nécessaire.

Citation:

---

Envoyé par Thierry Chappuis

Il est toujours possible, avec Python 3.0, d'utiliser l'ancienne syntaxe pour le formatage des chaines de caractères.

Thierry

---

Au temps pour moi. Le jour où j'avais testé le bidule j'avais dû écrire un print sans parenthèse ou une autre erreur débile, et j'ai cru que ça venait du %

Une chose est sûre, à terme il sera supprimé et sera marqué comme deprecated dès la version 3.1 : "The plan is to eventually make this the only API for string formatting, and to start deprecating the % operator in Python 3.1."

Tout ça pour dire que je comprend la philosophie globale du truc, du pourquoi string.format est plus puissant, plus "fonction", etc, mais globalement pour les petits scripts rapide, % marche très bien et il est carrément plus rapide à saisir. Je lui trouve le même interêt que les décorateurs de fonction par exemple. C'est du sucre syntaxique plaisant à manipuler, contrairement à string.format

Citation:

---

Envoyé par arnaudk

En fait, je n'ai pas compris pourquoi cette modification des strings formatter était nécessaire.

---

Pour proposer un outils encore plus puissant.

Thierry

Citation:

---

Envoyé par Thierry Chappuis

Pour proposer un outils encore plus puissant.

Thierry

---

Mais la philosophie de python était à la base de faire des trucs puissant avec des choses simples. Et on ne peut pas nier que la syntaxe % est beaucoup plus simple que la syntaxe du string.format, et que le % suffit à une grande majorité des cas usuels, si ? Je ne dis pas qu'il faut choisir l'un ou l'autre, mais qu'ils sont àmha complémentaires

Allez, je propose de créer un groupe Facebook "Je suis pour le maintien de l'opérateur % dans le langage python"

Aucune chance. Le dictateur a décidé que ça partirait.

Citation:

---

Envoyé par Matthieu Brucher

Aucune chance. Le dictateur a décidé que ça partirait.

---

N'empêche, juste pour le fun : http://www.petitiononline.com/PyString/petition.html

:)

go go go

L'ancienne mouture du formatage des chaînes semble surtout naturelle inconditionnels du C. De manière générale, je suis plutôt favorable à la nouvelle syntaxe.

Thierry

Bonjour,

Citation:

---

Envoyé par cho7

Mais la philosophie de python était à la base de faire des trucs puissant avec des choses simples. Et on ne peut pas nier que la syntaxe % est beaucoup plus simple que la syntaxe du string.format, et que le % suffit à une grande majorité des cas usuels, si ? Je ne dis pas qu'il faut choisir l'un ou l'autre, mais qu'ils sont àmha complémentaires

---

Je ne trouve pas que c'est logique de devoir connaître les tuples et la surcharge d'opérateur pour pouvoir comprendre comment le formatage peut fonctionner.

Citation:

---

Envoyé par Thierry Chappuis

L'ancienne mouture du formatage des chaînes semble surtout naturelle inconditionnels du C.

---

Gros +1, c'est un truc qui m'avait choqué quand je m'étais mis au Python.

Citation:

---

Envoyé par dapounet

Bonjour,


Je ne trouve pas que c'est logique de devoir connaître les tuples et la surcharge d'opérateur pour pouvoir comprendre comment le formatage peut fonctionner.

---

Quand j'avais découvert le python, je n'avais pas cherché à savoir ce que je mettais précisément derrière le %

Il y avait une syntaxe, je l'ai suivie. c'est tout hein :)