Discussion :

[fred1599]

Python, c'est bien pour prototyper ou si les algos se résument à des appels à numpy/scipy (dont une grosse partie du code est en C/C++/Fortran). Mais quand les algos deviennent plus complexes, la lenteur de python est souvent rédhibitoire. Et ça ne risque pas de changer, à cause de ses choix de conception (typage dynamique, pas de compilation JIT efficace, GIL...). Au boulot, on utilise de plus en plus Julia et ça nous change la vie.

Ce temps là est bien révolu, il faut se mettre à la page... Qui puis est travailler avec python simplifie et fait gagner beaucoup de temps sur le codage, mais en plus il s'interface avec des langages tels que le C/C++/Fortran. Je ne vois pas pourquoi s'en passer, même pour des algorithmes demandant beaucoup de performance.

Je connais Julia, c'est un super langage, il reste néanmoins qu'il a encore un certains manque de maturité, qui se comblera très vite je pense. Il y en a d'autres qui percent comme crystal, si tu as l'occasion de le tester et de l'utiliser au taf, vas-y !

P.S : Il n'y a pas que numpy/scipy dans la vie, si on cherche plus loin, voir cython, numba, panda, PyCuda, ... bref, c'est l'avantage de ce langage, le nombre de glues dans tous les domaines.

[Invité]

Ce temps là est bien révolu, il faut se mettre à la page...

Merci, ça fait toujours plaisir de se faire traiter d'arriéré. Donc Python est devenu performant, fait du typage statique optimisé et n'a plus de GIL ? J'ai dû faire un coma de plusieurs années...

Qui puis est travailler avec python simplifie et fait gagner beaucoup de temps sur le codage, mais en plus il s'interface avec des langages tels que le C/C++/Fortran.

Oui, c'est un peu ce j'ai dit en fait.

Je ne vois pas pourquoi s'en passer, même pour des algorithmes demandant beaucoup de performance.

Parce qu'en HPC, on cherche à maximiser les performances. Numpy/scipy et plein d'autres bibliothèques ont la moitié de leur code en C/C++/Fortran. Si Python était si performant, elles seraient 100% codées en python.

Je connais Julia, c'est un super langage, il reste néanmoins qu'il a encore un certains manque de maturité, qui se comblera très vite je pense.

Ah bah mince alors, je vis dans le passé mais dans un passé immature.

Il y en a d'autres qui percent comme crystal, si tu as l'occasion de le tester et de l'utiliser au taf, vas-y !

Ah oui, Crystal... il perce tellement qu'il faut presque toujours expliquer ce que c'est et indiquer sa page web... Crystal n'a pas les mêmes objectifs que Julia et n'est pas adapté au HPC actuellement.

[fred1599]

Merci, ça fait toujours plaisir de se faire traiter d'arriéré. Donc Python est devenu performant, fait du typage statique optimisé et n'a plus de GIL ? J'ai dû faire un coma de plusieurs années...

Je suis pas tout jeune, ça fait énormément de temps qu'on dit que python sert pour du prototypage. Effectivement il peut être utilisé pour ça... mais pas que pour ça ! Ah et j'oubliais, oui python fait du typage statique.

Parce qu'en HPC, on cherche à maximiser les performances. Numpy/scipy et plein d'autres bibliothèques ont la moitié de leur code en C/C++/Fortran. Si Python était si performant, elles seraient 100% codées en python.

Ouais pour ce cas très spécifique, on jette python dans la case prototypage ?

À savoir qu'on peut faire plus rapide que numpy/scipy avec cython par exemple, mais numba ça doit être possible aussi.

Ah oui, Crystal... il perce tellement qu'il faut presque toujours expliquer ce que c'est et indiquer sa page web... Crystal n'a pas les mêmes objectifs que Julia et n'est pas adapté au HPC actuellement.

Mais... parlait-on d'HPC dans notre discussion préalablement ? C'est ultra spécifique comme domaine, et il ne me semble pas qu'on parlait de python et HPC, mais bien de la limite que tu apportais à python, le prototypage de code.

[Invité]

oui python fait du typage statique.

Bien vu. Mais c'est encore loin d'être répandu et efficace : "The typing module has been included in the standard library on a provisional basis".

À savoir qu'on peut faire plus rapide que numpy/scipy avec cython par exemple, mais numba ça doit être possible aussi.

Réécrire les sections de code critiques en Cython (ou en C/C++/Fortran) demande un vrai travail. C'est d'ailleurs un des avantages de Julia que d'éviter ça.

Mais... parlait-on d'HPC dans notre discussion préalablement ? C'est ultra spécifique comme domaine, et il ne me semble pas qu'on parlait de python et HPC, mais bien de la limite que tu apportais à python, le prototypage de code.

Justement, je parlais du HPC spécifiquement, en réponse à un message précédent. Si tu avais lu correctement mon message avant d'y répondre, tu le saurais.

[RyzenOC]

Parce qu'en HPC, on cherche à maximiser les performances. Numpy/scipy et plein d'autres bibliothèques ont la moitié de leur code en C/C++/Fortran. Si Python était si performant, elles seraient 100% codées en python.

Oui et alors ?
On s'en fou de comment est codé Numpy, Opencl, ou cuda... ce qui compte c'est de les utiliser efficacement !

Le C/C++ n'est pas plus performant que python avec numpy... pour la simple et bonne raison que numpy est une lib optimisé.
Faire du from scratch en C/C++ serait contre productif pour un gain de perf (si tu en as un) ridicule.

Faire un code performant c'est tres difficle meme pour un expert en C, il est plus simple de partir sur des trucs tous fait, avec python je peut faire mes matrices avec numpy et faire des calcules sur gpu avec cuda/opencl sans passer 3ans pour le faire.
Avec Python je peut tous faire dans 1 seul programme et dans 1 seul "langage" (pycuda/pyopencl j'en conviens c'est pas du python mais il s’intègre très bien dans le code)
Une fois mes calcules fait je peut les afficher directement avec Vispy, ou si je veut faire de la 3D plus poussé j'utilise Panda3D voir je peut y intégrer du code opengl/vulkan pour les parties les plus critiques

Tous ceci dans 1 seul fichier .py

edit: pour le probleme des dépendances moi j’utilise anaconda portable, un simple copier-coller et hop mon code marche peu importe le cluster.

Je parle de numpy/scipy parceque ces lib ont une très bonne réputation dans le milieu, aucun autre langage n'a de lib comparable (scipy avec des centaines de formules toute faite comme la sigmoïde, la transformation de fourrier...etc)
J'ai pas essayer crystal (connait pas) par contre j'ai déjà fait des prototypes en Go et en julia mais j'ai pas été convaincue, je vois pas ce qu'ils offre de plus que python.
Pour python, il faut aussi savoir que Intel me donne une version optimisé pour ces cpu ce qui apporte un gros gain non négligeable.

[fred1599]

Justement, je parlais du HPC spécifiquement, en réponse à un message précédent. Si tu avais lu correctement mon message avant d'y répondre, tu le saurais.

Pas de mauvaise foi, là où je suis intervenu, c'est sur ta réflexion concernant les limites que tu apportes à ce langage, que je considère comme fausse... On ne peut pas dire que ce langage s'arrête à du prototypage de code.

Pour le HPC ne connaissant pas trop le domaine, je me suis pas permis d'exprimer sur ce sujet et je ne le veux pas.

[Invité]

Pas de mauvaise foi, là où je suis intervenu, c'est sur ta réflexion concernant les limites que tu apportes à ce langage, que je considère comme fausse... On ne peut pas dire que ce langage s'arrête à du prototypage de code.

Bon d'accord, tu as raison : je suis un arriéré de mauvaise foi qui ne sait pas lire et qui dit n'importe quoi.
Allez salut.

[Olivier Famien]

Python Software Foundation annonce qu’elle mettra fin au support de Python 2 à partir du 1^er janvier 2020
et prévient qu’elle n’apportera plus son aide pour tout problème lié à Python 2 après cette date

Depuis la sortie de Python 3.0, il est fortement recommandé d’abandonner les versions antérieures du langage de programmation Python au profit de cette dernière version. En mars dernier, Guido van Rossum, le créateur et leader du projet du langage de programmation Python, a annoncé que le support de la version 2.7 de python prendra fin le 1er janvier 2020. Après cette échéance, Python 2.7 ne bénéficiera plus d’aucune mise à jour, pas même pour des correctifs de sécurité. Bien évidemment, il est toujours possible que des développeurs indépendants fassent un fork de Python 2.7 pour assurer sa continuité. Mais pour Guido van Rossum, il ne faudra plus attendre de sa part et de son équipe des mises à jour ou même des décisions afférentes au développement de Python 2.7. Ce fait n’est pas sans importance, car dans la communauté Python, Guido van Rossum est considéré comme le dictateur bienveillant à vie.

Après l'annonce de Guido van Rossum, il était certain qu'une annonce plus officielle serait faite dans le même sens. Depuis quelques heures, la Python Software Foundation (PSF) a annoncé que le « 1er janvier 2020 serait le jour où elle mettra fin à Python 2. Cela signifie que nous ne l’améliorerons plus après ce jour-là, même si quelqu’un y trouve un problème de sécurité. Vous devriez passer à Python 3 dès que possible », suggère la fondation. Nous rappelons que la Python Software Foundation qui est composée de bénévoles a pour objectif de promouvoir, protéger et faire progresser le langage de programmation Python, ainsi que de soutenir et de faciliter la croissance de la communauté internationale des développeurs Python.

Selon la fondation, cette décision a été prise pour aider les utilisateurs de Python. Pour mieux se faire comprendre, la fondation donne les explications suivantes :

« Nous avons publié Python 2.0 en 2000. Quelques années plus tard, nous avons réalisé que nous devions apporter de grands changements pour améliorer Python. Donc, en 2006, nous avons lancé Python 3.0. Beaucoup de personnes n’ont pas effectué de mise à niveau et nous ne voulions pas leur faire de mal. Ainsi, depuis de nombreuses années, nous avons continué à améliorer et à publier Python 2 et Python 3 ».

« Mais cela rend difficile l’amélioration de Python. Il y a des améliorations que Python 2 ne peut pas gérer. Et nous avons moins de temps pour améliorer et accélérer Python 3. Et si de nombreuses personnes continuent à utiliser Python 2, les volontaires qui utilisent Python pour la création de logiciels en pâtissent. Ils ne peuvent pas utiliser les nouvelles fonctionnalités de Python 3 pour améliorer les outils qu’ils développent ».

« Nous ne voulions pas faire de mal aux utilisateurs de Python 2. Nous avons donc annoncé en 2008 que nous arrêterions Python 2 en 2015 et demandé aux personnes de passer à la version suivante avant cette date. Certains l’ont fait, d’autres pas. Donc, en 2014, nous avons prolongé cette échéance jusqu’en 2020 ». Mais à compter du 1^er janvier 2020, la PSF annonce qu'elle mettra fin au support de Python 2.

Pour les personnes qui s’entêteront et continueront à utiliser Python 2 après cette date, la fondation souligne que si elles « rencontrent des problèmes de sécurité catastrophiques dans Python 2 ou des logiciels écrits en Python 2 », les volontaires [de PSF] ne les aideront pas. « Certains de ces problèmes commenceront le 1^er janvier. D’autres problèmes s’aggraveront avec le temps », prévient PSF. En continuant à utiliser Python 3, « vous perdrez vos chances d’utiliser de bons outils, car ils ne fonctionneront que sur Python 3, et vous ralentirez les personnes qui dépendent de vous et travaillent avec vous ». Pour les logiciels écrits en Python 2, la PSF recommande de se tourner vers les outils de portage du code Python 2 vers Python 3. Certains développeurs qui sont passés de Python 2 à Python 3 affirment que cela a été la transition la plus facile jamais faite. Il existe une bibliothèque pour aider les développeurs à migrer leur code vers Python 3 et dans presque tous les cas, il est possible d’écrire du code compatible Python 2 et 3, fait remarquer un développeur.

Si par contre vous avez acheté un logiciel tiers déjà écrit en Python 2, il est conseillé de demander au fournisseur s’il dispose d’une assistance pour ce logiciel. Si ce n’est pas le cas, La PSF recommande quelques fournisseurs qui proposent contre rémunération une assistance technique pour Python 2. Nous avons Abilian, ActiveState, Python Academy et Snakedev.

Source : Python Software Foundation

Et vous ?

Quels commentaires faites-vous de la décision de la Python Software Foundation ?

Selon vous, devrait-on continuer à maintenir Python 2 ? Pour quelles raisons ?

Voir aussi

Meilleurs langages en 2019 selon l’IEEE : Python leader pour la troisième année consécutive, il s’impose dans tous les domaines dans lesquels il est utilisé, du développement web à l’embarqué
Meilleurs langages en 2018 selon l’IEEE : Python conforte sa place de leader grâce à son ascension dans le machine learning et l’embarqué
Netflix : Python est derrière chaque film que vous regardez, voici comment l’entreprise utilise le langage de programmation pour ses services
Python 3.8.0 : la première version bêta est publiée avec une API C pour améliorer la configuration de l’initialisation
Éducation : Python bientôt langage officiel de programmation en France ? Un projet dans le cadre de la réforme du Bac et du lycée

[Aspartame]

« Nous avons publié Python 2.0 en 2000....

la PSF a vraiment dit ça ... waou!

[Uther]

Bravo à Python pour avoir montré l'exemple de ce qu'il ne faut pas faire pour assurer une transition réussie. Et non ce n'est même pas ironique. La mésaventure de Python aura au moins servi d'exemple aux langages modernes qui se sont globalement bien mieux tiré du guêpier qu'est un changement incompatible, même si ça restera toujours quelque chose de compliqué.

Avec la fin du support de Python 2 on peut espérer que l'un des problèmes les plus récurrent de python disparaitra enfin.

[micka132]

La mésaventure de Python aura au moins servi d'exemple au langages modernes qui se sont bien mieux tiré (même si ça n'est toujours pas évident) du guêpier qu'est un changement incompatible.

Va dire ca aux utilisateurs d'Angular . Bon c'est un framework mais bon ca reste bien embêtant pour les pioneers qui ont participé à sa popularisation et qui se sont bien fait remercier!

[Andarus]

La mésaventure de Python aura au moins servi d'exemple au langages modernes qui se sont bien mieux tiré (même si ça n'est toujours pas évident) du guêpier qu'est un changement incompatible.

Tu pourrais citer des exemples ça m’intéresse?

[Uther]

Un exemple que je j'ai bien suivi est le langage Rust : il a mis en place un changement de syntaxe en 2018. Python et Perl ont clairement fait figure d'exemple à ne pas suivre lors des discutions sur la stratégie à adopter.
Leur solution finale a consisté à laisser chaque crate (l'équivalent du paquet) choisir l'édition qu'elle utilise(2015 ou 2018). Le compilateur est capable de compiler les deux éditions et les crates de différentes éditions peuvent interagir de manière totalement transparente.
Si l'édition n'est pas spécifiée c'est l'édition 2015 qui est employée, ainsi les anciennes crates continuent de fonctionner de manière totalement transparente, cependant l'outil qui crée les nouvelles crates définit par défaut la version à 2018.

J'ai moins suivi leur cas, mais il me semble que Go et Swift ont mis en place eux aussi des changements majeurs sans diviser lourdement leurs utilisateurs.

[stardeath]

ils auraient du abandonner python 2 dès que python 3 était suffisamment stable, dans les environ de 2010 si mes souvenirs sont bons.
là ils ont juste donné des excuses aux utilisateurs de python 2 pour ne pas migrer rendant au fur et à mesure la migration de plus en plus difficile.
de toute façon si les utilisateurs ne veulent pas migrer, ils feront tout pour ne pas le faire, autant dans ce cas ne pas s'emmerder avec ces personnes là, ils sont une perte de temps, autant se consacrer sur l'avenir et les gens qui le supporte.

[wiztricks]

de toute façon si les utilisateurs ne veulent pas migrer, ils feront tout pour ne pas le faire, autant dans ce cas ne pas s'emmerder avec ces personnes là, ils sont une perte de temps, autant se consacrer sur l'avenir et les gens qui le supporte.

Une stratégie de migration va dépendre du nombre d'utilisateurs impactés, de la quantité de bibliothèques à migrer pour qu'ils puissent migrer leurs propres applications et du coût, pour les différents développeurs, de maintenir une version python2 et une version "python3".

Et si la communauté Python était restée droit dans ses bottes, on aurait peut être eu droit à un fork pour tous ceux qui se sentaient un peu abandonnés.

A la place, nous avons eu des outils comme six qui permettent de maintenir des versions python2 et python3 assez facilement... Et plus de délais pour que cette migration ne soit pas une punition mais l'occasion d'apporter de nouvelles fonctionnalités aux utilisateurs finaux tout en profitant (un peu) de celles du langage.

Le choix étant comme toujours entre avancer plus vite et se retrouver un peu seul ou ralentir pour permettre aux autres de suivre.

- W

[stardeath]

selon mon expérience perso, dans les boites dans lesquelles je suis passé, la hiérarchie ne daigne pas regarder pour mettre les technos à jour tant qu'on leur met pas un couteau sous la gorge. donc plus de délais, pour moi ça signifie pas de migration et l'accumulation de code en python 2 qui augmentera la charge de travail lors de la vraie migration en python 3 car on aura plus le choix. (et j'ai testé les outils pour gérer python 2 et 3 en même temps, j'ai eu très vite envie de me pendre tellement ça rajoutait de contraintes)

pareil, dans les différentes boites où je suis passé, on est plus dans la stratégie de faire des commits unitaires, avec des fonctionnalités bien séparées et pas faire un commit fourre tout, pour être capable d'identifier plus facilement les problèmes entre les différentes versions, etc. (je vais pas faire la panoplie des avantages de pas modifier la terre entière à chaque commit), mais par contre dans ces mêmes boites, on n'applique pas la même stratégie pour la mise à jour des composants tiers ; là on attend le plus possible en faisant des bidouilles pas possible pour contourner les manques/bugs de ces composants, et dès que tu as le feu vert pour mettre à jour, il faudrait que ça soit immédiat et sans régression.

toujours pour moi, il faut arrêter ce double standard, soit on reste figé à un instant T, et on assume ; soit on se met à jour de façon régulière pour limiter les conséquences de delta trop important.

[wiztricks]

Salut,

selon mon expérience perso, dans les boites dans lesquelles je suis passé, la hiérarchie ne daigne pas regarder pour mettre les technos à jour tant qu'on leur met pas un couteau sous la gorge.

C'est une attitude humaine normale! Si on vous dit, il faut réaliser çà dans X mois, vous estimez la quantité de boulot à faire... Puis vous essayez de le facturer au client (car il faut bien vous payer à la fin du mois) et si la seule raison pour effectuer le boulot est juste d'être de conformité avec mais que çà n'apporte rien de plus aux utilisateurs (de l'application), c'est pas gagné.

pour moi ça signifie pas de migration et l'accumulation de code en python 2 qui augmentera la charge de travail lors de la vraie migration en python 3 car on aura plus le choix

Le client sait qu'il devra migrer au plus tard à la date X et combien çà risque de lui coûter en prestations et en interne (parce qu'il va certainement falloir immobiliser des employés pour tester un peu plus lourdement la chose).
Si l'application doit subir des évolutions majeures (et que toutes les bibliothèques externes sont disponibles), il peut en profiter pour "migrer": il optimise le coût des tests.

S'il n'y a que des opérations de maintenance, il va attendre... Et cela ne coûtera pas forcément plus cher car le coût d'une migration n'est pas une fonction du nombre de lignes de code ou des fonctionnalités (c'est plus compliqué) et il profitera de l'expérience acquise par les autres sur Python3 (en trouvant plus facilement des solutions en cherchant sur Internet).

Maintenant, si je suis une SSII et que j'ai 50 clients pour cette application, je sais que je peux essayer d'investir pour migrer car j'ai on espoir qu'in fine, X % de ces clients migreront (un jour)... et charger le coût sur X * 50.

Ce n'est pas le même scénario et chaque application a sa propre trajectoire en fonction de tas de considérations externes (la deadline - quand migrer au plus tard - en étant une parmi d'autres).

On n'applique pas la même stratégie pour la mise à jour des composants tiers ; là on attend le plus possible en faisant des bidouilles pas possible pour contourner les manques/bugs de ces composants, et dès que tu as le feu vert pour mettre à jour, il faudrait que ça soit immédiat et sans régression.

Ben oui, mais il suffit de regarder les contraintes économiques et les implications de changements de version qui posent toujours problème car il faut "tester" et on sait rarement si on a bien testé avant de balancer le truc en production. Donc... on tempère car on n'a pas envie de se faire fusiller par le directeur de la production ou le directeur des ventes qui va expliquer combien coûte un arrêt d'une heure, d'une journée,... sans compter les impacts sur l'image quand on ne peut pas consulter la base de donnée pour avoir l'état d'une livraison, d'une commande,...

C'est comme çà... bienvenue dans le monde de l'informatique d'entreprise.

Mais le gros soucis dans la migration Python3 a été la disponibilité des bibliothèques tierces. Car là, même si le client veut migrer, on ne peut pas (sauf à changer de bibliothèque mais les coûts sont autres).

- W

[Olivier Famien]

Alors que la fin du support de Python 2.7 approche à grands pas, certains utilisateurs manifestent leur réjouissance
tandis que d’autres affichent de la tristesse, comment accueilliez-vous la fin de Python 2.7 ?

En septembre dernier Python Software Foundation (abrégé PSF) qui a pour objectif de promouvoir, protéger et faire progresser le langage de programmation Python, ainsi que de soutenir et de faciliter la croissance de la communauté internationale des développeurs Python a annoncé que le « 1er janvier 2020 serait le jour où elle mettra fin à Python 2 ». Pour la fondation, cela signifie qu’aucune amélioration ne sera apportée au langage après ce jour-là, même si quelqu’un y trouvait un problème de sécurité. « Vous devriez passer à Python 3 dès que possible », a martelé PSF.

Il faut souligner que depuis 2015, il était prévu de mettre fin au support de Python 2.7. Mais face à la grande utilisation de cette version, cette première échéance a été reportée au 1er janvier 2020 afin de donner du temps supplémentaire aux individus et entreprises pour migrer vers Python 3. Après plusieurs années d’attente, 2020 est maintenant à la porte. Plus que 2 jours pour passer à la nouvelle année. Pour certains, c’est le lieu de se souvenir de tous les bons moments que l’on a pu passer avec cette version du langage. Aussi pour marquer la fin de Python 2, un utilisateur a eu l’idée de mettre en ligne un compte à rebours affichant le temps restant pour atteindre l’échéance fixée. Derrière cette démarche, l’utilisateur déclare qu’il souhaite organiser une fête pour rendre hommage à Python 2 à la conférence annuelle PyCon 2020 qui aura lieu du 15 au 25 avril 2020, aux États-Unis.

Si pour certains la fin du support de Python 2 constitue un moment de réminiscence des bons moments passés, pour d’autres par contre, c’est avec beaucoup de chagrin qu’ils abordent cette page qui tourne. Un utilisateur répondant au pseudonyme d’AlexMax confesse qu’il « ne peut pas s’empêcher de se sentir un peu triste ».

Pour lui, « à un niveau fondamental, la migration de 2 à 3 n’était rien de moins qu’un désastre complet, et a complètement tué son enthousiasme pour travailler avec le langage ». Comme arguments, il avance que les changements apportés dans Python 3 sont de nature à plus donner le mal de tête à ceux qui veulent effectuer la migration qu’à les encourager. Et pour cause, il met en avant les points suivants :

• la représentation fondamentale des chaînes de caractères a changé pour le pire et non le meilleur ;
• la gestion des paquets était et demeure un cauchemar en utilisant une combinaison d’environnements virtuels pip pour installer les dépendances spécifiques au projet ;
• comparé à d’autres langages, Python 3 est toujours lent, car il ne valoriserait que la simplicité par convention ;
• la bibliothèque asyncio permettant d’écrire du code concurrent en utilisant la syntaxe async/await aurait été ajoutée assez tardivement ;
• des indications de type ont été ajoutées au langage en s’appuyant uniquement sur des analyseurs statiques de type hinting au lieu de créer également des vérifications de type d’exécution dans le langage, ce qui aurait été beaucoup plus utile et cohérent, selon l’intervenant ;
• jusqu’à présent, il n’y a toujours pas de fonctions lambda anonymes multilignes.

Pour AlexMax, si l’équipe de développement de Python a reporté la première date de fin du support de Python 2.7, et s’il existe encore une forte population qui continue à utiliser Python 2.7, c’est parce qu’il n’y a pas suffisamment d’éléments motivants qui poussent à la migration vers Python 3. Au lieu de travailler à ces lacunes en implémentant de nouvelles fonctionnalités dans Python 3 pour convaincre les développeurs à migrer vers cette version, l’équipe de Python a plutôt agité le bâton en rappelant à chaque fois l’imminence de l’abandon de Python 2.x. Résultat, certains développeurs estiment qu’ils pourraient se tourner plutôt vers d’autres langages.

Pour d’autres utilisateurs par contre, bien que reconnaissant que la transition de Python 2 vers Python 3 n’aurait pas été bien gérée, Python 2 doit mourir. Pour ces derniers, les arguments de difficulté de gestion de paquets ne sauraient être mis en avant, car la gestion des paquets serait super simple avec Python. Pour ceux qui avancent le souci de mise à niveau de leurs projets, certains utilisateurs avancent qu’ils n’ont jamais rencontré de code Python 2 qui n’a pas pu être converti en un temps raisonnablement court en utilisant 2to3, à l’exception des modules d’extension en C, qui nécessitent un certain codage manuel, principalement en raison du changement d’Unicode. Et pour ceux qui ont fait le grand saut vers Python 3, certains avancent qu’ils n’ont jamais eu à regarder en arrière, car Python 3 aurait rendu le langage beaucoup plus cohérent.

Au-delà des réactions controversées relatives à la fin de Python 2.7, l’équipe de Python annonce que bien que le support de Python 2.7 s’arrête officiellement en janvier 2020, la version finale aura lieu après cette date. Ci-dessous le calendrier de la publication de la dernière version de Python 2.7 :

• 2.7.18 gel du code en janvier 2020 ;
• 2.7.18 la release candidate sera publiée en début avril 2020 ;
• 2.7.18 mi-avril 2020.

Après ces dates, ceux qui souhaiteront toujours utiliser Python 2.7 pourront se tourner vers une assistance tierce comme celle fournit avec RHEL qui compterait prendre en charge Python 2.7 jusqu’en 2024.

Source : Python, Python Clock

Et vous ?

Utilisez-vous encore Python 2.7 ? Pourquoi ?

Quel sentiment vous laisse la fin du support de Python 2.7 ?

Êtes-vous enthousiaste ou plutôt triste ?

Voir aussi

Meilleurs langages en 2019 selon l’IEEE : Python leader pour la troisième année consécutive, il s’impose dans tous les domaines dans lesquels il est utilisé, du développement web à l’embarqué
Meilleurs langages en 2018 selon l’IEEE : Python conforte sa place de leader grâce à son ascension dans le machine learning et l’embarqué
Netflix : Python est derrière chaque film que vous regardez, voici comment l’entreprise utilise le langage de programmation pour ses services
Python 3.8.0 : la première version bêta est publiée avec une API C pour améliorer la configuration de l’initialisation
Éducation : Python bientôt langage officiel de programmation en France ; ? Un projet dans le cadre de la réforme du Bac et du lycée

[RPGamer]

Passage déjà fait depuis longtemps et sans grande difficulté. Sans regret, adieux Python 2.

[gallima]

L’existence même d'une incompatibilité aussi majeur entre deux versions est le syndrome d'un langage mal née.

Allez, envoyez les pouces rouges.