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.
Commentaires (44)
#1
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
" />
#2
Ca me rappelle la fin de Windows XP tout ça 
" />
#3
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.
" />
#4
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.
#5
#6
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).
#7
#8
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.
#9
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.
#10
#11
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 : 7⁄2=3 et 4⁄2=2 mais 7.0/2=3.5
* En python 3 : la division de 2 entiers donne un float résultat de la division : Exemple 7⁄2=3.5 et 4⁄2=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.
#12
#13
#14
#15
Python évolue et il a bien raison. C’est comme ça qu’on s’améliore.
#16
#17
#18
#19
#20
#21
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.
#22
Courage!
#23
#24
#25
#26
Joyeux Noël!
" />
#27
De profundis. Et sans regrets.
#28
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.
#29
C’est le même qui a écrit les fichiers de configuration en yaml ?
" />
#30
#31
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.
#32
#33
#34
#35
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.
#36
#37
#38
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.
#39
#40
#41
#42
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.
#43
#44
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…