Discussion :

[Guigui_]

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.

[dividee]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[fodger]

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

[Musclor13]

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?

[Matthieu Brucher]

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.

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

[emmanuel_dumas]

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

[shadowsam]

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.

[Gwennin]

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

[kedare]

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

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

[cho7]

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

[Thierry Chappuis]

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

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

Thierry

[arnaudk]

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

[cho7]

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

[Thierry Chappuis]

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

Pour proposer un outils encore plus puissant.

Thierry

[cho7]

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"

[Matthieu Brucher]

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

[cho7]

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

[Thierry Chappuis]

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

[dapounet]

Bonjour,

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.

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.

[cho7]

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