Python 3.5.0 disponible avec une pile de nouveautés et améliorations
Faut-il maintenant mettre fin au support de Python 2.x ?
Le 2015-09-14 21:32:40, par Michael Guilloux, Chroniqueur Actualités
Alors que la sortie de Python 3.x a fait naître de vifs débats au sein de la communauté des développeurs, une nouvelle version stable du langage de programmation vient de voir le jour avec une pile de nouveautés et améliorations. Python 3.5.0 est en effet disponible depuis hier avec au menu, de nombreux changements et nouveautés dont les principaux sont entre autres :
Au sein d’une communauté de développeurs partagée entre Python 2.x et 3.x, ces améliorations pourraient peut-être inciter certains conservateurs à faire le pas vers Python 3.5. Les scientifiques et analystes de données en retireront probablement un gain avec par exemple l’introduction de l’opérateur pour la multiplication matricielle (@).
Pour rappel, les débats actuels sur les versions de Python résident dans le fait que certains développeurs ont trouvé trop brutale la transition entre 2.x et 3.x, à cause d’une certaine rupture de la compatibilité. S’il semble idéal de commencer les nouveaux projets Python avec les versions 3.x, toutefois la migration des projets existants pourrait s’avérer très coûteuse, pour les grands projets surtout. Pour cette raison, de nombreuses entreprises s’accrochent aux anciennes versions.
A l’opposé, les autres développeurs estiment que les améliorations apportées par Python 3.x, comme pour le support de l’Unicode sont assez suffisantes pour abandonner les versions 2.x. Certains estiment même que l’abandon du support de Python 2.x serait la bienvenue, dans la mesure où l’utilisation parallèle de ces différentes versions pourrait tuer le langage et entrainer un exode vers d’autres langages équivalents.
Et vous ?
- L’ajout du formatage % pour les objets bytes et bytearray ;
- L’ajout d’un nouvel opérateur pour la multiplication matricielle (@) ;
- Une nouvelle fonction d’itération de répertoire os.scandir () qui augmente la vitesse de la fonction os.walk () de 2 à 20 fois selon la plateforme et le système de fichiers ;
- L’ajout de support pour réessayer automatiquement les appels système interrompus ;
- Un changement à l'intérieur des générateurs lorsque StopIteration est levé ;
- Une nouvelle norme pour les annotations de type ;
- L’introduction de math.isclose (), une fonction pour tester l'égalité approximative ;
- Le lanceur Python de Windows peut désormais détecter les environnements virtuels ;
- L’élimination des fichiers .pyo des fichiers Python ;
- Un mécanisme nouveau et amélioré pour charger les modules d'extension ;
- L'amélioration du support des « applications zip Python ». Il s'agit d'une terminologie qui sera utilisée pour désigner une archive qui contient du code Python dans une forme qui peut être directement exécutée par Python. L'installateur Python 3.5 va associer les extensions .pyz (applications zip Python) et .pyzw (applications zip Pyhton sous Windows) aux plateformes correspondantes. Une extension a été spécifiquement définie pour Windows parce que l'installateur de Windows n'enregistrait pas une extension spécifique (autre que .py) pour ce type de format.
Au sein d’une communauté de développeurs partagée entre Python 2.x et 3.x, ces améliorations pourraient peut-être inciter certains conservateurs à faire le pas vers Python 3.5. Les scientifiques et analystes de données en retireront probablement un gain avec par exemple l’introduction de l’opérateur pour la multiplication matricielle (@).
Pour rappel, les débats actuels sur les versions de Python résident dans le fait que certains développeurs ont trouvé trop brutale la transition entre 2.x et 3.x, à cause d’une certaine rupture de la compatibilité. S’il semble idéal de commencer les nouveaux projets Python avec les versions 3.x, toutefois la migration des projets existants pourrait s’avérer très coûteuse, pour les grands projets surtout. Pour cette raison, de nombreuses entreprises s’accrochent aux anciennes versions.
A l’opposé, les autres développeurs estiment que les améliorations apportées par Python 3.x, comme pour le support de l’Unicode sont assez suffisantes pour abandonner les versions 2.x. Certains estiment même que l’abandon du support de Python 2.x serait la bienvenue, dans la mesure où l’utilisation parallèle de ces différentes versions pourrait tuer le langage et entrainer un exode vers d’autres langages équivalents.
Et vous ?
-
tyrtamosExpert éminentBonjour,
Python 3 est sorti en décembre 2008: c'est maintenant le Python "normal", et il continuera à évoluer, contrairement à Python 2.
Pour la conversion 2 => 3, il existe un petit code assez pratique (2to3.py) qui fait plus de 90% du boulot, et dont on peut automatiser facilement l'utilisation à une arborescence de codes (c'est ce que j'ai fait).
A mon avis, il faut des contraintes impératives pour continuer avec Python 2. J'en connais malheureusement une: mon hébergeur web qui a Python en CGI en est resté à Python 2, ce qui m'oblige à gérer quelques codes sous les 2 versions de Python. Il peut y en avoir d'autres, par exemple un module externe qui n'existe pas (encore) en Python 3 et dont on a absolument besoin, ou une très grosse application écrite en Python 2 qu'on doit continuer à faire évoluer sans la convertir.
A défaut de telles contraintes, continuer à coder en Python 2 est manifestement une impasse, puisqu'on se prive de toutes les évolutions présentes (à commencer par l’Unicode!) et futures de Python 3.le 15/09/2015 à 6:20 -
deusyssExpert éminentTout à fait d'accord. Cette version 3.5 présente de forts atouts et incitera je l'espère à migrer, à moins bien sur de n'avoir, comme tu le dis, un code compatible que 2.X.
Même s'il faut avouer qu'il ont pris un peu leur temps depuis 2008, et malgré quelques petits choix bizarre (on peu utiliser des accents dans le nom des variables maintenant), l'équipe de la fondation Python a réussit une migration superbe. le 15/09/2015 à 7:26 -
viandelleNouveau membre du ClubCertaines librairies très populaires ont mis, et c'est normal, du temps a être portée en 3.x
Maintenant tout est quasi au vert https://python3wos.appspot.com/le 15/09/2015 à 10:39 -
laerneMembre éprouvéMalheureusement, même toutes ces années après certaines bibliothèques n'ont pas migré vers python. Il y en a des très utiles*! Je constate que le monde du travail en entranché dans python 2 et ne voit pas l'avantage de migrer (ce qui n'est pas sans rapeller la situation avec certains OS…)
Bah.le 15/09/2015 à 10:38 -
wiztricksExpert éminent séniorCe débat là a déjà été tranché en avril 2014 et a conduit à réviser le PEP 373 pour y indiquer:De toutes façons, migrer une application qui fonctionne juste parce que sort une nouvelle version du langage ou de la bibliothèque "xy" sera toujours discutable et les arguments pour ou contre seront valables dans un contexte difficile à généraliser.Maintenance releases
====================
Being the last of the 2.x series, 2.7 will have an extended period of
maintenance. The current plan is to support it for at least 10 years
from the initial 2.7 release. This means there will be bugfix releases
until 2020.
- Wle 15/09/2015 à 18:37 -
genemartinMembre actifVous êtes sans doute des programmeurs, moi pas, je suis un scientifique qui écrit des scripts pour résoudre mes problèmes à l'aide essentiellement de modules scientifiques et spécialisés depuis plus de 15 ans et je ne me tracasse absolument pas de la version de Python installée, j'en ai plusieurs (de la 2.5 à la 3.5).
Pourquoi ? car, par exemple, j'ai encore des scripts en 2.5, qui font exactement ce que je veux avec des modules non portés sur les versions extérieures et je n'ai pas le courage de les mettre à jour en cherchant des modules équivalents, seul le résultat final compte. J'en ai d'autres en 2.7.x (comme ceux liés aux SIGs (Systèmes d'Information Géographiques) qui utilisent Python comme langage de script) et en 3.x pour bénéficier de traitements plus spécialisés.
Donc je jongle et personnellement je ne vois pas pourquoi les diverses versions seraient mutuellement exclusives (2.x ou 3.x), mais, je le répète, je ne suis pas programmeur (plutôt un scripteur) et dans le monde scientifique, les choses informatiques vont sans doute plus lentement (ce n'est pas le sujet des recherches). Il y a, par exemple, un grand nombre de modules spécialisés liés à à des librairies C ou Fortran qu'il serait difficile de migrer.
J'ai déjà dû migrer des versions 1.x vers les 2.x, et des versions 2.4 vers la 2.5 puis la 2.6, puis...Donc ma philosophie est maintenant d'utiliser une version x suivant les circonstances et honnêtement, quand on connait Python, ce n'est pas très difficile de passer de l'une à l'autre dans la majorité des cas.
Lorsque R est passé de la version 2.x à la 3.x, il n'y a pas eu autant de controverses, les gens se sont adaptés et les 2 mondes coexistent encorele 17/09/2015 à 14:51 -
cervoMembre avertiMoi j'suis pour le renforcement des compatibilités Python 2.x & 3.x , python2.x est bien enraciné ! même si je pense que c'est le moment de migrer !le 15/09/2015 à 13:43
-
JiyuuRédacteur/Modérateur
J'ai migré sur Python 3 il y a quelques années déjà. Ne programmant, actuellement, que pour moi et pour le plaisir majoritairement, il est vrai que le passage c'est fait sans douleur.
Je pense qu'il est tant de migrer de Python 2 à 3. Comme l'a dit Tyrtamos, dans beaucoup de cas ce passage est facilité avec 2to3.py. Ainsi le développeur pourra bénéficier de toutes les nouveautés qui sont apparues, qui apparaissent et qui vont encore apparaitre à l'avenir.
On parle beaucoup des bibliothèques qui ne sont pas encore arrivées pour Python 3, (au passage dans le lien de viandelle, reportlab est marqué en rouge alors qu'il est bien porté sous Python 3 il me semble) mais je trouve qu'on ne parle pas assez de celles qui n'exploite plus ou pas Python 2.
Je pense par exemple à PyQt 5 pour laquelle Riverbank ne publie plus d'installateur windows pour Python 2. Je n'ai pas essayé d'installer depuis les sources, c'est probablement possible d'y arriver, mais pas sans y laisser quelques neurones je pense.
Que l'on soit en Python, C++, Java, ... toutes les techno qui fonctionnent fort évoluent constamment. Je crois que le développeur doit, à un moment ou l'autre, se faire violence et accepter ces évolutions s'il ne veut pas passer à coté de nouveautés intéressantes.
Pour finir, n'y-a-t-il certaines bibliothèques qui, elles aussi ayant évolué, permettent de remplacer celles non portées sous Python 3 ?le 15/09/2015 à 15:02 -
Sve@rExpert éminent séniorBonjour
Je travaille sur 4 projets en parallèles qui totalisent 467 fichiers et plus de 325000 lignes de code. Et en plus j'utilise PyQwt, une librairie arrêtée en 2012 et remplacée par guiqwt. Donc pour moi, un passage à p3 se fera dans la douleur (ou plutôt je pense dans la longueur, en intégrant préalablement guiqwt à la place de PyQwt). Hé oui, l'utilisation d'outils non portés sont des contraintes auxquelles il faut penser quand on parle de migration.
Ceci dit, j'y pense quand-même de plus en plus fréquemment. D'où le saut à pieds joints que j'ai fait sur ce sondagele 15/09/2015 à 18:49 -
dsyMembre habituéSalut
Alors justement, argumente
En quoi trouves-tu multiprocessing assez chiant à utiliser ?
Je pourrais poser la même question pour les performances mais c'est souvent un débat sans fin.le 03/10/2015 à 7:45