Discussion :

[Michael Guilloux]

Python 3.5.0 disponible avec une pile de nouveautés et améliorations
Faut-il maintenant abandonner Python 2.x pour les versions 3.x ?

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 :

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

En savoir plus sur les nouveautés dans Python 3.5.0

Et vous ?

Que pensez-vous des améliorations et nouveautés ? Qu’est-ce que vous auriez aimé voir dans cette nouvelle version ?

Pensez-vous qu’il est maintenant temps de passer de Python 2.x vers Python 3.x ? Pourquoi de nombreuses entreprises utilisent-elles encore Python 2.x ? Faudrait-il envisager la fin de son support ?

Forum Python

[tyrtamos]

Bonjour,

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.

[deusyss]

Bonjour,

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.

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

[laerne]

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.

[viandelle]

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

Certaines 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/

[cervo]

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

[Jiyuu]

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 ?

[wiztricks]

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.

Ce débat là a déjà été tranché en avril 2014 et a conduit à réviser le PEP 373 pour y indiquer:

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.

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.

- W

[Sve@r]

Bonjour
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 sondage

[genemartin]

Vous ê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 encore

[RyzenOC]

Personnellement ce qui me gène avec python c'est qu'il ne gère pas les threads en natif et le module multiprocessing est assez chiant a utiliser.
Je trouve Python pas assez performant, python 3.5 a t'il eu des optimisations par rapport a 3.4 ?


Pour ma part j'utilise PyPy.

[dsy]

Personnellement ce qui me gène avec python c'est qu'il ne gère pas les threads en natif et le module multiprocessing est assez chiant a utiliser.

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.

[RyzenOC]

En quoi trouves-tu multiprocessing assez chiant à utiliser ?

La mémoire n'est pas partager par défaut.
Je trouve sont implémentation plus complexe que les threads (notamment quand on code en objet ou j'ai du bidouillé pour crée une méthode qui lance un processus dans ce même objet)

Pour moi cela est tous sauf simple et intuitif:

Code :

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

1
2
3
4
5
6
7
8
 
if __name__ == "__main__":
    p = Pool(initializer = init, initargs = (counter, ))
    i = p.map_async(analyze_data, inputs, chunksize = 1)
 
    # autre technique tout aussi moche:
    manager = Manager()
    x = manager.Value('i', 0)

Hors le but de python c'est de codé vite, bien et facilement.

Sinon on peut utiliser des variable global, mais bon pour moi c'est plus du bricolage qu'autre chose.

Autre problème (qui n'a rien avoir avec le module en lui même), la plupart des bibliothèques ne sont pas safe-thread, le cas par exemple avec tkinter, obliger de crée une nouvelle instance à chaque thread, et processus.