Sortie de Python 3.1 : Stabilisation et optimalisation

Sortie de Python 3.1 release



Le célèbre langage de programmation Python est désormais disponible en version 3.1. Succédant à une version 3.0, qui représentait un grand tounant pour le langage, cette nouvelle mouture corrige près de 370 bogues, et s'est concentré sur sa stabilisation et son optimisation.
Ainsi le module entrée/sortie a été réécrit en C pour améliorer ses performances, la gestion du 64 bits s'est améliorée. A noter également un ajout intéressant : un nouveau type pour les dictionnaires ordonnés, très attendu par la communauté.

Citation:

---

Python 3.1 final was released on June 27th, 2009.

Python 3.1 is a continuation of the work started by Python 3.0, the new backwards-incompatible series of Python. Improvements in this release include:

• An ordered dictionary type
• Various optimizations to the int type
• New unittest features including test skipping and new assert methods.
• A much faster io module
• Tile support for Tkinter
• A pure Python reference implementation of the import statement
• New syntax for nested with statements

---

:arrow: http://www.python.org/download/releases/3.1/



Selon vous, cette nouvelle version suffira-t-elle à faire migrer les développeurs restés avec Python 2.* ou ayant migré vers les alternatives IronPython, Jython, etc ?


:merci:

Python 3.1 : Stabilisation et optimalisation

Une nouvelle version du langage Python est désormais disponible, pour corriger certains bugs qui ont été constatés et surtout pour proposer une meilleure stabilité et optimaliser les nouvelles fonctionnalités présentes dans Python 3.0.

Le langage Python
C’est un langage de programmation, d’abord gratuit, qui fonctionne tout aussi bien sur les environnements tels que Windows ou Unix, que MacOs ou MSDOS. Il se base sur une approche modulaire et une programmation orientée objet. Largement adopté par de nombreux développeurs Python mérite la fidélité de ses adeptes qui sont toujours à l’affût de ses nouvelles versions.

Version 3.1
Si l’on revient un peu sur Python 3.0, pas moins de 370 problèmes ont été recensés par les utilisateurs pendant ses mises en œuvre. D’où la sortie presque impérative d’une nouvelle version pour rassurer ses nombreux fidèles et pour promouvoir davantage l’utilisation des logiciels gratuits. Et comme les défaillances tournaient principalement autour des nouvelles fonctionnalités des efforts notables ont été déployés par les développeurs et les concepteurs pour lui apporter plus de fiabilité et d’efficacité.
C’est ainsi que la librairie des entrées/sorties a été ré-écrite en langage C, langage de programmation système par excellence. Et selon les tâches lancées, les performances ont augmenté d’un facteur pouvant varier de 2 à 20. De plus, lors d’une compilation avec GCC, ICC ou SunPro, l’exécution du code du programme Python gagne jusqu’à 20% en vitesse. De même que pour les caractères UTF, leur décodage se passe avec un délai quatre fois moindre qu’avant. Le module json bénéficie également d’une nette amélioration de ses performances dès qu’on lui a doté d’une extension en C.

64-bits
Evolution et révolution obligent, Python se doit d’intégrer le cercle encore relativement restreint de la communauté 64-bits (Microsoft 2010 vient d’y adhérer assez récemment). Ce qui offrira à sa base de stockage une meilleure disponibilité quant à la mémorisation des nombres entiers. Naturellement, une nette différence se ressentira au niveau des ordinateurs (acceptant les versions sous 64-bits) sur les vitesses d’exécution.

Autres nouveautés
Mais bien d’autres nouveautés sont également présentes dans Python 3.1. Comme, par exemple, les dictionnaires ordonnés qui apportent de précieuses aides à ses utilisateurs en économisant énormément les temps de consultations. Et si vous procédez à une modification d’une clé, elle ne changera pas de sa position d’origine lors d’une prochaine cession. En outre, sur la présentation des nombre, dorénavant Python 3.1 est à même d’intégrer des séparateurs de milliers conformément aux exigences syntaxiques de chaque langue. L’utilisateur n’aura plus qu’à choisir le format générique adapté à la langue qui lui convient.

Bref Python devient de plus en plus redoutable, comme un python.

Citation:

---

An ordered dictionary type

---

C'est très utile ceci. A titre personnel, je vais faire la migration pour cela.

De mon côté, wait and see.
J'attends que py2exe et pyserial soit compatibles avant de basculer.

Moi j'attends que wxpython soit compatible poour faire le grand saut :ccool:

Je suis passé à cette version. Il y a des petites choses
perturbantes comme les objets map mais c'est pas mal surtout avec
la version 8.5 de Tk

Citation:

---

Envoyé par gorgonite

Selon vous, cette nouvelle version suffira-t-elle à faire migrer les développeurs restés avec Python 2.* ou ayant migré vers les alternatives IronPython, Jython, etc ?

---

Disons que les gros modules pourront passer, puisque c'est une version stabilisée de la 3.0 avec quelques améliorations.
Ensuite, pour IronPython, Jython, ... la question ne se pose pas. Les utilisateurs de ces implémentations le font pour des raisons que CPython 3 ne peut pas satisfaire. En revanche, c'est l'implémentation de référence qui fera que ces autres implémentations pourront bientôt/un jour aussi supporter ces modifications du langage.

Citation:

---

Envoyé par Annaelle32

Le langage Python
C’est un langage de programmation, d’abord gratuit, qui fonctionne tout aussi bien sur les environnements tels que Windows ou Unix, que MacOs ou MSDOS.

---

C'est un langage et CPython 3.1 est la dernière implémentation de référence de ce langage, et il se trouve que cette implémentation est gratuite.
En revanche, MSDOS n'est plus supporté depuis longtemps, il me semble que les Windows < 2000 ne le sont plus ou ne le seront bientôt plus.

Il semble que le support 64 bits se soit amélioré, mais c'est surtout pour le monde Windows, il me semble. Pour Linux, les versions précédentes passent aussi sur du 64bits (j'ai 2.5 maison, et il me semble que RH4 a un 2.3 qui doit aussi être en 64bits).

La non-compatibilité ascendante est un très mauvais choix.
Beaucoup de boîtes ont fait un investissement très fort sur Python.
Il n'y a pas que les bibliothèques. Il y a les 'frameworks' et puis les applications bâties avec ces'frameworks', et puis les 'plugins' développés pour ces applications. La chaîne du développement est longue...
Je connais certains professionnels très irrités par cette situation.
Je préfère Python à java (il n'y a pas photo) mais il arrive que je sois obligé d'utiliser Java (principalement pour écrire des applets). Et bien j'utilise des biblithèques Java vieilles de plus de 10 ans (calcul matriciel, graphisme, etc...) et tout passe sans le moindre problème.
Bien sûr, in fine, je ferai comme tout le monde, et travaillerai avec la version 3.00, mais pour le moment je me bats encore pour des problèmes de compatibilité entre 2.5 et 2.6, alors 3.00 est encore loin.

Citation:

---

Envoyé par Zavonen

Et bien j'utilise des biblithèques Java vieilles de plus de 10 ans (calcul matriciel, graphisme, etc...) et tout passe sans le moindre problème.

---

Exact, et c'est pour ça que Java est truffé d'inconsistance, parce qu'ils se repose sur la même base qui ne peut pas évoluer.
La compatibilité ascendante c'est bien, mais au bout d'un moment il faut abandonner des vieux standards qui nous empêchent de mettre en place de nouvelles bonnes idées.
Exemple: En Python3, toutes les fonctions range, map, filter etc. bref toutes les fonctions standards qui renvoyaient des listes renvoient maintenant des itérables ! Et comme dans 90% des cas ces listes ne servaient qu'à être itérées elle prenaient une place inutile en mémoire ! Avec les itérables : un seul élément utile à la fois = un seul élément chargé en mémoire à la fois. (Cela rejoint le principe de l'évaluation paresseuse, qui est tellement pratique parfois. Oui, je suis Haskelleur, aussi). Et quand bien même on a vraiment besoin d'avoir toute la liste en mémoire, ben : list(range(...)) et zou.
(c'est la même chose pour le duo x86-compatible/ARM, le premier se base sur une archi vieille de plusieurs dizaines d'années, et le second a des perfs supérieures et une consommation bien moindre parce qu'il accepte d'évoluer)

Ce n'est pas pour plomber les boîtes qui utilisent Python (tout le monde et moi le premier est très content de voir ce langage reconnu à sa juste valeur et utilisé en entreprise), mais Python est open-source à la base, c'est une communauté qui le fait évoluer selon ce qui est le mieux pour lui, pas une poignée oligarchique de décideurs comme pour un langage propriétaire (ex: WinDev/WLangage, l'allégorie de ce type de langage).
En gros, Python doit s'adapter aux besoins de TOUS, pas uniquement ceux des entreprises.

Citation:

---

Envoyé par limestrael

Exact, et c'est pour ça que Java est truffé d'inconsistance, parce qu'ils se repose sur la même base qui ne peut pas évoluer.

---

Java est, à mon sens, le langage qui a la plus grosse cohérence dans sa biblio standard...
Certes ils ont gardé les anciennes pour permettre aux vieux logiciels de tourner. Rien ne force toutefois les développeurs à se servir de ces vieilles librairies pour leurs nouveaux programmes: ce serait même idiot.

Je prends pour exemple de cette évolution flagrante et pourtant bien intégrée l'arrivée des Generics (classes paramétrées), les annotations, les stubs RMI qui se compilent automatiquement etc...
De plus, les conventions de nommage et indentation sont restées inchangées depuis longtemps. (Ce n'est pas le cas de PHP par exemple...)

Maintenant je n'ai que quelques années de développement derrière moi, il y a sans doute des incohérences que je ne vois pas. Dans ce cas, indique les.


Il n'en reste pas moins que le passage non rétro-compatible à Python 3 est une bonne chose.
Ca permet de supprimer quelques hérésies comme le fait que print n'était qu'un statement.
Ils ont l'air d'en profiter aussi pour améliorer les performances.
Mais est-ce une amélioration par rapport aux 2.x, ou par rapport à la 3.0 ?

Citation:

---

Ca permet de supprimer quelques hérésies comme le fait que print n'était qu'un statement.

---

Peux-tu m'expliquer ce point s'il-te-plait ?
Je n'ai jamais eu à pâtir du fait que print soit une instruction.
Si vraiment on a besoin d'une fonction:
def myprint(x):
print x
et c'est tout!

Ca ajoute de la mécanique dans le parser et dans l'arbre syntaxique. A la fin, il s'agit d'une simplification de ces éléments qui permettent un code plus petit (même si c'est de pas beaucoup), un arbre potentiellement mieux optimisable, ...

Citation:

---

Envoyé par Zavonen

Peux-tu m'expliquer ce point s'il-te-plait ?

---

Ce qu'a dit Matthieu est très vrai.

De plus, les statements (bon, quel est le mot français pour ça déjà ?) ont pour vocation de définir la structure d'un code. if, class, def, return, raise etc...

print et exec (et peut-être d'autres auquels je ne pense pas), ne définissaient pas de structure, mais accomplissaient une action.
Or, l'action est bien le rôle d'une fonction, non d'un statement. A mon sens, c'est une incohérence de langage.

Enfin, l'utilisation de print comme une fonction offre plus de flexibilité.

Citation:

---

Ca ajoute de la mécanique dans le parser et dans l'arbre syntaxique.

---

Aucun doute, ce que tu dis est certainement vrai. Mais cela me paraît tellement mineur comme argument pour invalider d'un coup des millions de petits programmes utilisant l'instruction 'print'. Il aurait peut être été plus avisé de créer une fonction 'display' de conserver 'print' en recommandant l'usage de 'display' et en redirigeant 'print' vers 'display'.
Dans l'ensemble je constate que la nouvelle version 3.00 et + est plutôt bien accueillie en France et particulièrement sur ce forum, mais que ce n'est pas le cas aux USA où le qualificatif de 'red herring' revient souvent, ce qui n'est pas vraiment flatteur.
La plupart des forums font également état de performances 10% moins bonnes (pystones) entre 2.6 et 3.0.
Pour ce qui me concerne, je n'utilise pas Python d'une manière vraiment professionnelle (uniquement pour des programmes de démo - mais pas de démo du langage), et j'ai déjà pas mal de problèmes entre 2.51 et 2.6 au niveau de l'utilisation de certaines bibliothèques.
Personne ne remet en doute les qualités fondamentales du langage, et la confiance dans l'équipe de développement mais je crois que je ferai comme beaucoup d'autres j'irai vers 3.10 en 'traînant les pieds'.

Certes, votre remarque est juste, mais vous oubliez une chose : personne ne vous oblige à passer à Python 3 du jour au lendemain. Et il me semble que les devs de Python n'ont pas cette prétention ;)

Tout va se faire doucement et progressivement les bibliothèques passeront à Python 3 jusqu'à ce qu'elle devienne la version de référence.