Python 3.0, qu'en pensez-vous ?

**dj.motte** · 26/02/2009, 22h24

Envoyé par arnaudk

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

Effectivement c'est inutilement compliqué. Si le module ctype survit on pourra toujours appeler la fonction de la librairie en C.

Entre python 2.5 et 2.6 il y a 612 bugs et 256 patches. Alors on se demande ce qui va se passer entre la 2.6 et la 3.0 en termes de bugs ?

Si chaque version corrige des bugs pour en créer d'autres cela ne sert à pas grand chose.

Mais bon le multi-tâche de la 3.0 c'est bien entre autres. Mais je ne vois pas la nécessité de rompre avec la compatibilité ascendante.

Salut.

**Thierry Chappuis** · 27/02/2009, 08h00

Envoyé par dj.motte

Mais je ne vois pas la nécessité de rompre avec la compatibilité ascendante.

Certes avec Python 3.x, il y a rupture de la compatibilité ascendante, mais il y a les 2.x pour assurer cette compatibilité. Tu as donc le choix entre ces 2 versions majeures, et la branche 2.x n'est pas prête de disparaître.

Globalement, le nettoyage opéré par Python 3.x est plutôt une bonne chose. Lorsqu'on y regarde de près, les incompatibilités sont pas si nombreuses que cela. J'ai essayé de migrer un petit projet avec l'outil 2to3, ça fonctionne plutôt bien.

Thierry

**kromartien** · 03/03/2009, 23h18

Envoyé par fodger

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.

Je marche dans le troll, mais bon ...

En parlant de bonnes pratiques de la programmation python, cela n'a rien à voir avec de la programmation en C. Python est plus expressif, et il est encouragé de faire des codes concis et clairs, également pour des raisons de performance. Si on sait faire un code C propre, ce n'est pas pour ça qu'on sait faire un code Python propre. Ça demande une connaissance du langage et de la POO beaucoup plus poussée que le C.

Concernant le passage à py3k, il est déjà déconseillé de de passer tout de suite à la nouvelle version.

Personnellement, pour tous les projets qui utilisent des librairies externes, il ne vaut mieux pas s'aventurer dans une éventuelle migration, mais plutôt attendre que les bibliothèques utilisées soient passées à py3k.

Enfin, je suis un peu inquiet pour certaines bibliothèques qui ne sont plus maintenues, qui risquent probablement de disparaître pour cause de cassage de la compatibilité ascendante et du manque de mainteneur...

Je pense que ça démontre qu'il vaut mieux utiliser des librairies avec une bonne communauté derrière...

**yorukaze** · 01/04/2009, 11h16

simple question, qu'apporte le fait que print devienne une fonction? Au final le resultat sera le même. Je suis curieux voila tout

**dapounet** · 01/04/2009, 11h37

Bonjour,

Envoyé par yorukaze

simple question, qu'apporte le fait que print devienne une fonction? Au final le resultat sera le même. Je suis curieux voila tout

Par exemple tu peux choisir de ne pas séparer les paramètres par des espaces, sans passer par str.format().
Et les paramètres se passent normalement à la fonction, il n'y a plus besoin de faire print >> sys.stderr, 'pouet'.
Et ça permet aussi de remplacer print() par un autre objet.

**kromartien** · 01/04/2009, 18h39

Envoyé par yorukaze

simple question, qu'apporte le fait que print devienne une fonction? Au final le resultat sera le même. Je suis curieux voila tout

Surtout, ça préserve une certaine homogénéité du langage, ce qui est fondamental avec Python.

**Thierry Chappuis** · 01/04/2009, 20h35

On peut également utiliser un appel à print() dans des contextes ou une instruction n'est pas acceptée, par exemple dans le corps d'une fonction lambda. C'est plus lisible que sys.stdout.write().

Par ailleurs, c'est à mon avis moins ésotérique d'écrire:

Code :

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

1
2
3
 
for i in range(10):
    print(i, end=" ")

plutôt que

Code :

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

1
2
for i in range(10):
    print i,

Thierry

**bruno_pages** · 03/04/2009, 19h11

Bonjour,

N'utilisant pas Python cela me permet d'avoir un regard extérieur, et j'avoue être très surpris de voir que vous parlez principalement de print et //, même si cela posera effectivement un problème de compatibilité (ce qui agace toujours, ne me parlez pas de Qt4

) il s'agit quand même de détails

Par contre, personne en dehors d'une simple remarque d'anthyme ne se félicite de la possibilité d'indiquer au niveau des opérations le type des paramètres et de la valeur rendue. Il s'agit juste d'annotations, mais c'est nettement plus propre que le palliatif actuel consistant à l'indiquer dans un commentaire.

Python ne rime pas avec 'génie logiciel' ?

P.S. si je ne suis pas teinté Python, je suis très teinté C++ et UML, ce qui n'est évidemment pas sans rapport avec ma remarque, probablement naïve

**Tyrus** · 03/04/2009, 19h20

Des type c'est quoi un type ?

Non sérieusement oui c'est vrai que c'est une fonctionnalité bien sympathique pour la documentation généré automatiquement et pour l'auto complétion dans les IDE.

**kromartien** · 03/04/2009, 22h22

Envoyé par bruno_pages

Par contre, personne en dehors d'une simple remarque d'anthyme ne se félicite de la possibilité d'indiquer au niveau des opérations le type des paramètres et de la valeur rendue. Il s'agit juste d'annotations, mais c'est nettement plus propre que le palliatif actuel consistant à l'indiquer dans un commentaire.

Python ne rime pas avec 'génie logiciel' ?

P.S. si je ne suis pas teinté Python, je suis très teinté C++ et UML, ce qui n'est évidemment pas sans rapport avec ma remarque, probablement naïve

Bah, à vrai dire, je me suis posé la question de l'utilité d'indiquer les types en tant qu'annotation, mais je pense que c'est pas forcément génial. En effet, on a toujours le crédo "explicite est meilleur que implicite", dans le zen of python.

Si quelque chose n'a pas besoin d'être explicité par une annotation supplémentaire, c'est peut être mieux, à la fois pour la concision, et aussi pour le fait que la simple lecture d'une fonction permet de deviner le rôle et le type de ses arguments. C'est peut être un peu meilleur selon moi, maintenant je ne pense pas que je me servirai de ces annotations personnellement, car je ne crois pas qu'elles aient un rôle fondamental à jouer dans l'écriture d'un programme.

Pour ce qui est de la documentation automatiquement générée, en tous cas, c'est vrai que c'est un point très positif. Cela permet de décrire immédiatement tous les objets passés en argument, sans se référer au contexte du codage, qui n'est pas visible lorsqu'on se concentre sur les méthodes externes et leur utilisation. C'est donc très positif selon moi pour cette utilisation et le développement de bibliothèques bien documentées.

**kedare** · 12/04/2009, 05h09

vous savez si python3 met les "new style class" par defaut sans avoir a préciser d'hériter d'object ?

**Thierry Chappuis** · 12/04/2009, 08h45

Envoyé par kedare

vous savez si python3 met les "new style class" par defaut sans avoir a préciser d'hériter d'object ?

Oui, plus besoin d'hériter d'object pour créer une classe nouveau style.

Thierry

**kedare** · 12/04/2009, 20h12

Par contre j'avais entendu parler d'une re-écriture total des IO extrêmement lente dans python3k, jusqu'à 50x plus lente que l'actuelle qui est déja lente (par apport a java par exemple) il me semble.... et ca sera optimisé que dans python3.1, ca c'est naze, et je retrouve plus la source de ca...

on vois ca ici par exemple :
http://bugs.python.org/issue4533
0.033s avec python2.5
36.8s avec python3.0
c'est donc plus de 1000x plus lent

**Matthieu Brucher** · 12/04/2009, 20h21

Effectivement, cio arrive dans la 3.1. Les IO ont été réécrites pour ne pas se baser sur les les IO C qui sont parfois surprenantes par rapport à Python (il y a aussi différentiation entre les IO binaires et texte).

**kedare** · 12/04/2009, 20h25

Envoyé par Matthieu Brucher

Effectivement, cio arrive dans la 3.1. Les IO ont été réécrites pour ne pas se baser sur les les IO C qui sont parfois surprenantes par rapport à Python (il y a aussi différentiation entre les IO binaires et texte).

mais c'est carrément inutilisable avec cette lenteur en IO, non ?