« Fin du monde » pour des développeurs au 1er janvier 2020 : Python 2.7 ne sera plus mis à jour

Le 20 décembre 2019 à 09h10

1 min

Logiciel

Une chose est sûre, personne ne pourra dire qu’il n’était pas au courant. Le statut EOL (End of Life) de la version 2.7 pour début 2020 était connu depuis 2014.

Et encore, les développeurs avaient décidé à cette époque d’accorder un délai supplémentaire de cinq ans puisque la fin du support était prévue pour 2015. L’annonce avait été faite en… 2008, quand est arrivée la version 3.0 de Python, qui n’est pas rétrocompatible avec la branche 2.x

Bref, plus de 10 ans après l’annonce initiale, elle sera effective dans quelques jours. Un site propose même un décompte à la seconde près. Après cette date, plus aucune mise à jour ne sera proposée.

Comme le rappel Anaconda, cela ne signifie pas que les projets utilisant Python 2.7 (et ils sont encore nombreux aujourd’hui) cesseront de fonctionner, mais en cas de faille de sécurité il faudra vous débrouiller.

S’agissant d’un projet open source, n’importe qui peut créer un « fork » et continuer à travailler dessus. Vous pouvez également vous tourner vers des sociétés tierces proposant des services de maintenance payants.

Sébastien Gavois

Le 20 décembre 2019 à 09h10

Commentaires (44)

barlav Abonné

Le 21/12/2019 à 14h04

Joyeux Noël!

" />

Carboline Abonné

Le 21/12/2019 à 14h27

De profundis. Et sans regrets.

tazvld Abonné

Le 21/12/2019 à 20h27

La grande majorité des bibliothèques que tu as citées existe en python3 (certaine cité doivent même venir avec python.)

Sinon, oui, tu peux avoir 2 python d’installer, il faudra juste lancer avec le bon interpréteur “python2 monscript.py” ou “python3 monscript.py”(python lance celui par défaut). Sous une debian, les interpréteurs python devrait être dans le dossier “/usr/bin/”, par exemple python 2.6 : “/usr/bin/python2.6”.

Mais je te conseille même d’utiliser un “venv”. Ca permet de spécifier gérer un environnement python par projet, avec la version de python et des bibliothèques à utiliser.

spidermoon

Le 21/12/2019 à 21h33

C’est le même qui a écrit les fichiers de configuration en yaml ? " />

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 22/12/2019 à 08h29

spidermoon a écrit :

C’est le même qui a écrit les fichiers de configuration en yaml ? " />

Oui… J’ai failli citer YAML et Markdown. Même combat. Tous ces trucs c’est génial quand c’est petit, mais par exemple si tu veux générer automatiquement à partir d’un préprocesseur (p. ex. pour ajouter un peu partout le même texte) c’est le foutoir parce que tu dois en permanence vérifier qu’il y a bien la bonne indentation, le bon nombre de lignes blanches.

Bref, j’ai tout jeté, ge génère plutôt du json ou du html.

Quiproquo Abonné

Le 22/12/2019 à 08h57

C’est un peu périmé, Calibre est déjà porté vers python3. La seule chose qui retarde la migration définitive, c’est qu’il va falloir porter les plugins tiers.

Ricard

Le 22/12/2019 à 10h28

Carboline a écrit :

De profundis.

De profundis Morpionibus. " />

empty

Le 22/12/2019 à 13h11

Quiproquo a écrit :

C’est un peu périmé, Calibre est déjà porté vers python3. La seule chose qui retarde la migration définitive, c’est qu’il va falloir porter les plugins tiers.

Ha cool. Merci pour l’info.

flan_ Abonné

Le 22/12/2019 à 13h24

yl a écrit :

En même temps, quand on n’est pas fichu d’offrir une compatibilité ascendante absolue (en général, ce type de pb est le symptôme d’erreurs de conception initiales) sur un langage de programmation, il ne faut pas s’étonner que les utilisateurs ne se bousculent pas pour porter ce qui fonctionne.

" />

Mais le but était de corriger un certain nombre d’erreurs de conception, et il n’était pas possible de garder une compatibilité parfaite tout en corrigeant ces erreurs (genre bytestring et Unicode strings). 

Ils ont préféré corriger ces erreurs, et tant mieux car beaucoup de bugs très fréquents en Python 2 ne se voient plus en Python 3.

SebGF Abonné

Le 23/12/2019 à 06h24

C’est un gros souci de gestion de l’obsolescence des composants applicatifs de ne pas faire de maintenance évolutive sur ce point.

J’espère que ce n’est pas une application qui gère de la donnée sensible, sans quoi c’est même un sacré risque de sécu !

M’enfin, j’ai pas vu beaucoup de DSI qui se souciaient du patch management et des versions de composants… Ca n’a commencé à changer que depuis le RGPD vu de ma fenêtre. " />

anonyme_6d3c8325027b08b8beb8eb7f143f3660

Le 23/12/2019 à 07h53

mizuti a écrit :

La “fin” entre guillemet " />

ouais j’en ai encore retrouvé un il y a deux mois

mizuti

Le 23/12/2019 à 09h17

darkbeast a écrit :

ouais j’en ai encore retrouvé un il y a deux mois

Au boulot on a encore besoin de déployer du XP pour administrer certain vieux composant…

js2082

Le 23/12/2019 à 09h29

De toute façon, tout le monde sait que le seul  vrai langage de programmation valable est l’assembleur.

Tout le reste n’est que broutille et fainéantise de programmeurs qui ont peur d’user leurs doigts sur un clavier.

" />

Aloyse57

Le 23/12/2019 à 11h57

js2082 a écrit :

De toute façon, tout le monde sait que le seul vrai langage de programmation valable est l’assembleur.

Tout le reste n’est que broutille et fainéantise de programmeurs qui ont peur d’user leurs doigts sur un clavier.

" />

Ouais. Surtout qu’avec ça, personne ne pouvait espérer devenir programmeur en 2 semaines, ni même récupérer du code direct sur internet sans le décortiquer au complet 😆

crocodudule

Le 23/12/2019 à 14h22

empty a écrit :

non, Kodi 19 tu veux dire (qui n’est pas encore sorti)

Kodi 18 est en python 2.7

La médaille du grand réfractaire revient à l’auteur de Calibre (gestion d’ebook) qui refuse de passer à python 3 et préfère maintenir lui-même python 2.7 " />

Je ne suis pas apte à juger du sérieux de la chose, mais c’est pas rien.

" />

Depuis la 18.4 (ou 5?) je pense que python 2.7 a dégagé, du moins certaines librairies puisque par exemple le plugin google music ne fonctionne plus (sans bidouille) car il cherche une lib qui n’est plus présente sinon sous un autre nom dans la version 3 de phyton.

Certains ont repris le plugin pour le faire pointer là où il faut (par contre comme ils ont fait ça chacun dans leur coin, ils ont nommé les versions n’importe comment…).

Ah oui effectivement il est totalement barré ^^

anonyme_f6b62d162990fde261db0e0ba2db118e

Le 23/12/2019 à 15h04

yl a écrit :

En même temps, j’en conviens, quand on a par exemple des ; en délimiteur de fin de ligne de programme c’est clair.

 Pareil d’ailleurs quand on a des {} pour les blocs et qu’on ne se repose pas sur la seule indentation: Ça évite des bugs vicieux ou une fin de bloc éditée avec 2 éditeurs configurés différemment présentent visuellement un alignement mais qu’a l’exécution ces lignes de fin se trouveront exclues du bloc.

Perso j’aime beaucoup l’obligation d’indenter et de ranger son code.

Parce que je le fais déjà en Java ou autre pour avoir un code lisible,

Parce que ça oblige mes collègues à faire du code lisible. (enfin, disons un minimum " /> ) Quand leur indentation nécessite un écran 50”, ils commencent doucement à se dire qu’un truc cloche.

Cela dit, Python permet aussi certaines écritures bien sales que d’autres langages n’autorisent pas…

C’est  finalement plus une histoire de goût qu’autre chose je pense.

L’abandon de 2.7 est plutôt bienvenu dans mon équipe, le dvpt et la maintenance hybrides commençaient à être un peu lourds… On pourra plus facilement refuser de partir sur 2.7 pour un nouveau projet " />

ErGo_404

Le 24/12/2019 à 07h16

Je développe avec mon équipe des back-ends entiers en python. Ce que tu présentes ne s’est produit qu’une fois ou deux, il y a longtemps, parce qu’on travaillait sur des éditeurs mal branlés.

Aujourd’hui les éditeurs détectent automatiquement le style d’indentation et ils permettent d’afficher un caractère à la place des espaces si vraiment tu as peur. Il reste le cas du copier/coller où il faut juste vérifier que tu as bien collé avec le bon niveau d’indentation, mais même ça est bien pris en charge par les éditeurs.

flan_ Abonné

Le 25/12/2019 à 10h35

ErGo_404 a écrit :

Je développe avec mon équipe des back-ends entiers en python. Ce que tu présentes ne s’est produit qu’une fois ou deux, il y a longtemps, parce qu’on travaillait sur des éditeurs mal branlés.

Aujourd’hui les éditeurs détectent automatiquement le style d’indentation et ils permettent d’afficher un caractère à la place des espaces si vraiment tu as peur. Il reste le cas du copier/coller où il faut juste vérifier que tu as bien collé avec le bon niveau d’indentation, mais même ça est bien pris en charge par les éditeurs.

Tout à fait d’accord ; de façon plus générale, quand on utilise de bons outils (je suis un grand fan de PyCharm, personnellement), on n’a aucune erreur d’indentation et c’est très, très, rare d’avoir des erreurs de type car c’est également détecté à l’écriture. Personnellement, j’indique très souvent le type des variables, à la fois pour aider l’IDE à me détecter les erreurs et pour faciliter la relecture par un tiers. 

Ensuite, black (qui reformate le code pour que tous les codeurs aient le même style) me semble être maintenant un outil indispensable, que j’applique avant chaque commit. Je sais que j’utiliserais un équivalent dans n’importe quel langage tellement je trouve ça pratique.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 26/12/2019 à 08h48

Pffff bande de débutants… Il y a quelques mois on a (enfin) migré notre dernière machine physique Windows 2000 vers une VM (mais toujours en Win2000 " />).

Il doit traîner une ou deux machines Windows 95 et en cherchant bien je pense pouvoir retrouver la VM qui contient un Windows for Workgroups 3.11 où tourne encore la première mouture du soft. Ce qui est pratique avec WfW3.11 c’est que tu peux aller sur Internet sans antivirus et sans firewall, aucun risque de se prendre un malware " />

Ah oui, dans le bureau d’un collègue il y a encore un portable qui boote en … MS DOS 6 (bon, oui, pas souvent, ça doit faire 2 ans qu’on n’en a plus eu besoin). J’installerais bien un Linux dessus, mais je ne retrouve plus mon CD-ROM Yggdrasil de 1993…

DoWnR Abonné

Le 20/12/2019 à 09h47

C’est bien beau d’avoir un plan à long terme et de bien prévenir à l’avance du EOL, mais l’inertie des utilisateurs fait qu’ils n’ont de toute façon commencé à s’en inquiéter que cette année… et d’autres semblent attendre encore la date ultime " />

KooKiz Abonné

Le 20/12/2019 à 09h53

Ca me rappelle la fin de Windows XP tout ça " />

Le 20/12/2019 à 10h03

En même temps, quand on n’est pas fichu d’offrir une compatibilité ascendante absolue (en général, ce type de pb est le symptôme d’erreurs de conception initiales) sur un langage de programmation, il ne faut pas s’étonner que les utilisateurs ne se bousculent pas pour porter ce qui fonctionne.

" />

hansi

Le 20/12/2019 à 10h21

Vu les avantages évidents de Python 3, en particulier l’UTF-8, et le fait que la migration des projets de 2.X vers 3.Y se fait sans trop de problèmes, la décision de fin de support me semble pour une fois logique et aller dans le bon sens. Quant à faire comprendre aux clients qu’un programme, ça s’entretient, et que l’entretien à forcément un coût, c’est toujours la même problématique commerciale, tout OS confondu.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 20/12/2019 à 10h31

yl a écrit :

ce type de pb est le symptôme d’erreurs de conception initiales

Tout le monde est bien d’accord que Python est bourré d’erreurs de conception. Python 3 a pu en corriger certaines, mais d’autres seront éternellement présentes.

Dont la pire est mise en évidence par l’ami Gustave lui-même :

https://bertrandmeyer.com/2019/12/01/adult-entertainment-2/

crocodudule

Le 20/12/2019 à 11h32

Kodi 18 n’intègrant plus 2.7 pas mal d’extensions ne fonctionnent plus (du moins sans bidouiller un peu, ce que bien des utilisateurs sont incapables de faire), y compris des extensions présentes sur le dépot officiel.

Clairement je le regrette pas: il y aura probablement encore pendant quelques temps des extensions qui ne fonctionnent plus, mais ça imposera à kodi de faire un peu le ménage (y compris chez lui).

crocodudule

Le 20/12/2019 à 11h36

hansi a écrit :

Vu les avantages évidents de Python 3, en particulier l’UTF-8, et le fait que la migration des projets de 2.X vers 3.Y se fait sans trop de problèmes, la décision de fin de support me semble pour une fois logique et aller dans le bon sens. Quant à faire comprendre aux clients qu’un programme, ça s’entretient, et que l’entretien à forcément un coût, c’est toujours la même problématique commerciale, tout OS confondu.

Le code est généralement facilement portable, ça peut se compliquer pour certaines librairies.

anonyme_f3cfc6423586ba6bed42154d795b2b3f

Le 20/12/2019 à 11h48

Pour les barbus linuxiens, c’est comme si on leur disait qu’ils allaient devoir prendre une douche, le choc va être dur à digérer.

skankhunt42

Le 20/12/2019 à 12h24

C’est vraiment facile de migrer un projet 2.6 / 7 sur du 3.x ? Je crois qu’a l’époque j’ai pas installé la version 3 car certains plus n’était pas disponible.

tazvld Abonné

Le 20/12/2019 à 12h33

yl a écrit :

En même temps, quand on n’est pas fichu d’offrir une compatibilité ascendante absolue (en général, ce type de pb est le symptôme d’erreurs de conception initiales) sur un langage de programmation, il ne faut pas s’étonner que les utilisateurs ne se bousculent pas pour porter ce qui fonctionne.

" />

Python2 n’était pas parfait, c’est même assumé par les concepteur. Certain point de conception initiales étaient mauvais (par exemple “print” à l’origine est un instruction du langage, est devenu une fonction en python3. Les exceptions sont maintenant des objets. La division d’entier donne un float et non plus un entier…), certain inconsistant (surtout au niveau des nom de modules), d’autre point sont aussi une évolution des technologies, ainsi les chaîne de caractères par défaut sont passé d’un ISO à de l’unicode/UTF8 (ce qui permet même d’utiliser des accents dans les commentaires.)…

Dans une bonne partie des cas, le module 2to3 devrait faire le taf pour convertir un ancien code python2 en python3.

Enfin de nombreux codes sont écrits pour être compatible 2 et 3 à l’aide de la bibliothèque “__future__” qui fait en sorte que python2 (récent) se comporte comme un python3.

Après, je te rassure, la très grande majorité des utilisateurs ont basculé sur python3, il n’y a que des avantages. Seuls les vieux cons codent encore en Python2. Ce qui pose problème, c’est surtout des codes qui ne sont plus du tout maintenu.

tazvld Abonné

Le 20/12/2019 à 12h47

Pffff, pas toujours.

2to3 va faire une bonne grosse partie de taf automatiquement. Mais certaine subtilité qui ont changé ne peuvent pas être fait automatiquement.

Je pense par exemple à la division de 2 entiers.

* En python 2 : la division de 2 entiers donne un entier résultat de la division entière. Exemple : ⁷⁄₂=3 et ⁴⁄₂=2 mais 7.0/2=3.5

* En python 3 : la division de 2 entiers donne un float résultat de la division : Exemple ⁷⁄₂=3.5 et ⁴⁄₂=2.0

En python3 la division entière est réalisable avec l’opérateur “//” : 7//2=3 et 4//2=2 mais aussi 7.0//2=3.0

Comme python est dynamiquement typé, le type est connu à l’exécution. Avec le code seul, il est difficile de savoir quoi utiliser.

LostSoul Abonné

Le 20/12/2019 à 14h17

JeSuisGentil a écrit :

Pour les barbus linuxiens, c’est comme si on leur disait qu’ils allaient devoir prendre une douche, le choc va être dur à digérer.

mais +1 quoi " />

empty

Le 20/12/2019 à 15h30

crocodudule a écrit :

Kodi 18 n’intègrant plus 2.7 pas mal d’extensions ne fonctionnent plus

non, Kodi 19 tu veux dire (qui n’est pas encore sorti)

Kodi 18 est en python 2.7

La médaille du grand réfractaire revient à l’auteur de Calibre (gestion d’ebook) qui refuse de passer à python 3 et préfère maintenir lui-même python 2.7 " />

Je ne suis pas apte à juger du sérieux de la chose, mais c’est pas rien.

" />

WereWindle

Le 20/12/2019 à 15h40

empty a écrit :

La médaille du grand réfractaire revient à l’auteur de Calibre (gestion d’ebook) qui refuse de passer à python 3 et préfère maintenir lui-même python 2.7 " />

Je ne suis pas apte à juger du sérieux de la chose, mais c’est pas rien.

" />

En gros, Python lui as dit “on passe en v3 obligatoire, là” et il leur a répondu “Fork you !” " />

Watchwolf

Le 20/12/2019 à 15h40

Python évolue et il a bien raison. C’est comme ça qu’on s’améliore.

M4lyk Abonné

Le 20/12/2019 à 16h10

WereWindle a écrit :

En gros, Python lui as dit “on passe en v3 obligatoire, là” et il leur a répondu “Fork you !” " />

" />

gg40 Abonné

Le 20/12/2019 à 16h20

LostSoul a écrit :

mais +1 quoi " />

 

 Bah ouai c’est lourd

Edit : d’abandonner la branche 2

mizuti

Le 20/12/2019 à 16h42

KooKiz a écrit :

Ca me rappelle la fin de Windows XP tout ça " />

La “fin” entre guillemet " />

Ricard

Le 20/12/2019 à 18h17

JeSuisGentil a écrit :

Pour les barbus linuxiens, c’est comme si on leur disait qu’ils allaient devoir prendre une douche, le choc va être dur à digérer.

Je suis Linuxien (glabre " />) et je code en Python. J’ai arrêté Python2.7 depuis au moins 5 ans.

Ricard

Le 20/12/2019 à 18h18

skankhunt42 a écrit :

C’est vraiment facile de migrer un projet 2.6 / 7 sur du 3.x ? Je crois qu’a l’époque j’ai pas installé la version 3 car certains plus n’était pas disponible.

Ca dépend de la taille du projet.

spidermoon

Le 20/12/2019 à 23h22

Je suis sur un projet Node (version 8.11) en maintenance, qui utilise Python 2 (ou peut-être juste quelques modules parmi les centaines téléchargés automatiquement par le jeu de dépendances) Et pas question de passer sur une version Node plus récente, car qui dit projet en maintenance dit projet en prod et budget de maintenance uniquement pour corrections de bug et petites évolutions.

barlav Abonné

Le 21/12/2019 à 04h24

Courage!

Le 21/12/2019 à 06h48

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Dont la pire est mise en évidence par l’ami Gustave lui-même :

https://bertrandmeyer.com/2019/12/01/adult-entertainment-2/

En même temps, j’en conviens, quand on a par exemple des ; en délimiteur de fin de ligne de programme c’est clair.

 Pareil d’ailleurs quand on a des {} pour les blocs et qu’on ne se repose pas sur la seule indentation: Ça évite des bugs vicieux ou une fin de bloc éditée avec 2 éditeurs configurés différemment présentent visuellement un alignement mais qu’a l’exécution ces lignes de fin se trouveront exclues du bloc.

Python 3 préviens désormais, certes, mais au fond c’est encore peinture sur merde = propreté.

En arriver à pouvoir exécuter un truc différent de ce qu’on voit m’avait fait immédiatement prendre ce langage avec des pincettes. Le concepteur faisait une fixette sur la présentation, certes importante, mais troquer l’obligation à indenter proprement par ce truchement contre le risque d’exécuter un truc différent de ce qui est présenté je trouve cela bête et dangereux. Et aucun “beautifier” ne sait ici rattraper cela a coup sûr (il faut lire et comprendre le bout de code pour savoir de quel côté ça doit se situer à l’exécution) quand dans la plupart des langages ce genre d’outil remets sans risque d’erreur au goût de celui qui le reprends un source un truc présenté à son goût (ou selon les règles de codage du groupe ou on travaille).

 

Python est AMHA allé trop loin à singer le langage naturel. Tous les langages permettent certes de manière détournée de faire des trucs difficiles à lire, mais il faut un peu le vouloir, rien de naturel dans l’affaire. Ici une formulation naturelle pour l’un va faire réfléchir l’autre avec la liberté offerte, au delà même des faiblesses ci-dessus.

Le 21/12/2019 à 07h03

tazvld a écrit :

La division d’entier donne un float et non plus un entier…)

 

Le genre de trucs à lui seul capable de ne causer que des problèmes sans en résoudre aucun!

 Autant celui qui voulait en python 2 un résultat flottant savait parfaitement y parer et l’aura fait avec conversion explicite d’opérande en écrivant son code. Autant celui qui porte un code existant (qui ne voulait pas de conversion) datant un peu va se faire avoir avec une probabilité proche de 100% avec un comportement inexact de son programme à la clef.

Les côtés casse-gueule de python (c’est pas le seul qui m’ait posé pb, pourtant j’en ai pas fait beaucoup!) expliquent sans doute bien des comportements “vieux con” (selon toi).

 

skankhunt42

Le 21/12/2019 à 13h50

Ricard a écrit :

Ca dépend de la taille du projet.

C’est pas tant la taille mais le nombre de libs et de machines que j’utilise. Pi serial pour la com avec l’arduino, tkinter pour l’interface graphique, truc machin pour les math, conf, csv, stats, images, html. Puis clone sur le pc portable relié à la machine.

Possible d’avoir les deux version de python installés sur une même machine toujours avoir une version qui marche ? J’ai pas envis de me retrouver coincé avec un truc à la con sans erreur et devoir farfouiller des heurs sur le net pour trouver une réponse.

Catégories

Nous Suivre

À propos

« Fin du monde » pour des développeurs au 1er janvier 2020 : Python 2.7 ne sera plus mis à jour

Commentaires (44)