En 2017, Python 2.7 est encore plus utilisé que la version 3.x dans les projets commerciaux

Version imprimable

19/10/2017, 02h26
Malick

2 pièce(s) jointe(s)

En 2017, Python 2.7 est encore plus utilisé que la version 3.x dans les projets commerciaux

En 2017, Python 2.7 est plus utilisé (63,7 %) que la version 3.x dans les projets commerciaux,
selon Semaphore CI

« Parmi tous les langages de programmation actuellement en vogue, Python est celui qui détient la plus forte proportion en termes de croissance » ; ces propos sont ceux de Semaphore CI, un fournisseur de solutions de Continous Integration & Delivery. Sa plateforme du même nom (Semaphore CI) serait aujourd'hui utilisée par des milliers d'entreprises situées un peu partout dans le monde.

Du fait de son intérêt pour le langage Python, Semaphore CI s'est décidée, comme l'année précédente, à faire une analyse de l'ensemble des nouveaux projets à caractère commercial qui sont hébergés sur sa plateforme afin de savoir quelles sont les versions de Python qui ont été utilisées pour leur développement. Au terme de ses travaux, Semaphore CI conclut que sur l'année 2017, près de 63,7 % des projets sont développés à partir de la version 2.7 de Python contre 36,3 % de projets développés avec la dernière version de ce langage à ce jour à savoir Python 3.x.

Pièce jointe 320603

Semaphore CI rappelle qu'en 2016, son rapport faisait apparaître une utilisation de Python 2.7 pour le développement de projets commerciaux à plus de 70 %, ce qui traduit une baisse de près de 8,2 % en 2017. Par analogie, les résultats pour Python 3.x se sont un peu améliorés passant de moins de 30 % en 2016 à 36,3 % en 2017.

« La version stable de Python 3.0 a été publiée en décembre 2008 ; toutefois, la plupart des membres de la communauté n'ont pas encore procédé à la mise à niveau de leurs projets, comme on s’y attendait. La version Python 2.7 quant à elle a été publiée en juillet 2010 soit il y a de cela 7 ans déjà et à ce jour, la date relative à l'arrêt de sa maintenance n'a pas encore été fixée puisqu'elle est utilisée dans la majorité des projets », déclare Semaphore CI.

En ce qui concerne les différentes versions de Python 3.x utilisées sur sa plateforme, Semaphore CI soutient que l'analyse des informations collectées montre que les équipes qui ont opté pour Python 3 ont trouvé plus pratique de faire une mise à niveau vers une version plus récente. L'année dernière, 60 % d'entre eux ont utilisé la version de Python 3.5 et 39 % ont utilisé Python 3.4. Cependant, en 2017, la majorité (43 %) utilise toujours la version 3.5, et environ 35 % des projets utilisent la version 3.6. Le nombre de projets exécutant Python 3.4 par contre est de 20 %.

Pièce jointe 320607

L'éditeur de la plateforme Semaphore conclut son analyse en soutenant que les changements de version enregistrés dans la communauté des utilisateurs de Python 3 se produisent très rapidement.

Source : Blog Semaphore

Et vous ?

:fleche: Que pensez-vous des résultats de l'analyse de Semaphore ?

:fleche: Pensez-vous, comme Semaphore, que Python est le langage qui détient le plus fort niveau de croissance ?
19/10/2017, 11h06
jdddeschamps

Apprendre le python 3.x en priorité

Personnellement, je préconise d'apprendre le python, et le python 3 en priorité :
https://www.developpez.net/forums/bl...rendre-python/
Sauf pour faire de la maintenance d'application en python 2.x.
Je suis navré qu'il existe encore autant de nouveaux projets en python 2.x. Cela met de l'entropie et contribue à faire de l'apprentissage de la programmation un parcours du combattant.
Heureusement, la perspective est quand même à une nette progression du python 3.x.
19/10/2017, 11h09
Jamatronic

Cet article est une façon de rappeler que le(s) inventeur(s) de Python n'ont pas estimé utile de maintenir une compatibilité ascendante totale entre versions 2 et versions 3.

Rien que pour ça, boycott total de ce langage !
19/10/2017, 11h18
transgohan

Citation:

Envoyé par Jamatronic

Cet article est une façon de rappeler que le(s) inventeur(s) de Python n'ont pas estimé utile de maintenir une compatibilité ascendante totale entre versions 2 et versions 3.

Rien que pour ça, boycott total de ce langage !

J'irai pas jusqu'à dire boycott mais c'est ce qui fait qu'on a jamais sauté le pas vers la version 3...
Devoir reprendre des milliers de scripts c'est casse gueule... C'est pas pour rien que dans le milieu bancaire il y a encore des vieux langages qui sont utilisés, c'est le même problème.
Python 3 a totalement été mal réfléchi... C'est déjà heureux que cela n'ai pas été un fiasco.
19/10/2017, 11h43
wiztricks

Salut,

L'article porte sur les projets qui utilisent la plateforme d'intégration continue Semaphore.... (qui utilise cette plateforme?).
Si on regarde d'autres populations comme les développeurs qui utilisent PyCharm... on trouverait autre chose.

Citation:

Envoyé par Jamatronic

Cet article est une façon de rappeler que le(s) inventeur(s) de Python n'ont pas estimé utile de maintenir une compatibilité ascendante totale entre versions 2 et versions 3.

S'ils avaient voulu maintenir une compatibilité ascendante, la nouvelle version aurait été 2.8 et non 3.x... Et s'ils pensaient que la migration de l'existant vers la version 3 était facile, ils ne supporteraient plus la version 2.7 depuis longtemps.

- W
19/10/2017, 12h41
pboulanger

2.x vs 3.x

Le changement de 2.x vers 3.x peut certes être coûteux et risqué en fonction de la volumétrie de la base installée, je vous le concède. Et c'est le frein qui empêche aujourd'hui certaines migrations.

Par contre la volonté de faire une 3.x avec des incompatibilités a été décidé afin de rendre le langage plus cohérent et plus simple: de nombreux artefacts historiques ont été retirés comme le changement de print qui n'était pas une fonction et ne pouvait pas être passée comme paramètre/argument d'une fonction... La généralisation des itérateurs et des générateurs permet aussi d'avoir un comportement par défaut plus simple et compréhensible....
D'autres langages ont aussi connus ce type d'évolutions: essayer de recompiler un code C++ écrit avec VC6 sur VS2010 et vous aurez d'énormes surprises: le portage d'une application backoffice financier de VC6 à VS2010 m'a pris environ 16 mois de travail lors d'une de mes missions...

Les specs de la V4 sont en cours avec un objectif fixé à 2023 me semble-t-il... Refuser de passer à la V3 augmentera le coût de passage à la V4...
19/10/2017, 17h13
Invité

Citation:

Envoyé par pboulanger

D'autres langages ont aussi connus ce type d'évolutions: essayer de recompiler un code C++ écrit avec VC6 sur VS2010 et vous aurez d'énormes surprises

Ça n'a rien à voir. Ça c'est une incompatibilité entre des versions de compilateurs (et assez spécifique à visual d'ailleurs). Contrairement à Python, le langage C++ assure justement la compatibilité ascendante donc un compilateur C++17 peut compiler du code C++98.
06/11/2017, 13h25
RyzenOC

c'est bien dommage

C'est très dommage

j'ai pour ma part tous fait évoluer mes projets en python 3.X
C'est pas une partie plaisante mais elle n'est pas impossible, quasi toutes les libs ont migré sous python3 et les changements de syntaxe entre python2 et python3 sont pas non plus gigantesque.

Python2 avait trop de probleme de cohérence dans le langage il fallait repartir sur une base plus saine.
Perso cela m'aggace de voir par exemple des dev encore écire print "hello world" en python 2.7. La bonne pratique est d'écrire print("hello world")

Moi en tous cas j'ai tous fait évoluer donc python2.7 c'est le passé.
Certaines distrib linux ont enfin viré tous leurs vieux scripts python2.7 et on enfin migré.

Bon par contre pour la V4 j'espere qu'il n'y aura pas trop de changement car python3.6 me semble quand meme cohérent y'a pas de bizzarerie dans le langage qui justifirais de tous recasser.
Par contre pour la V4 je pense qu'il y'aura une refonte du GIL. Il y'a des travaux en cours tres intéressant permettantde de faire un programme multicoeur sans les contraintes de la GIL et du multiprocessing. La gil ne disparait pas et ne dispaitra je pense jamais mais offira enfin plus de souplesse.