Fin du support de python 2.7?

133

Existe-t-il une date / heure connue à laquelle python 2.7 ne sera plus pris en charge en faveur de python 3?

— Stiivi
source

8

Une bonne question tant qu'il n'y a pas de doublon, je ne pourrais en trouver aucun.

— Matt Joiner

2

Cette question semble être hors sujet car elle concerne le support d'une version linguistique

— bummi

1

La meilleure vue d' ensemble que je pourrais trouver est ce tableau: docs.python.org/devguide/#status-of-python-branches

— Matth

Au début de 2018, la date butoir a été spécifiée plus précisément: nous sommes maintenant le 1er janvier 2020. Lorsque les distributions avec le changement "python" pour pointer vers "python3" est une question plus ouverte.

— ESR

stackoverflow.com/a/58401685/5025009

— seralouk

109

Depuis le 13 avril 2014, sur http://hg.python.org/peps/rev/76d43e52d978 (PEP 373, Python 2.7 Release Schedule):

La date de fin de vie (EOL, date d'expiration) pour Python 2.7 a été déplacée de cinq ans dans le futur, à 2020. Cette décision a été prise pour clarifier le statut de Python 2.7 et soulager les inquiétudes des utilisateurs qui ne peuvent pas encore migrer vers Python 3 Voir également PEP 466 .

— Marco Mariani
source

23

@Basic Sauf que ce n'est pas plein de vulnérabilités.

— Stian OK

5

@StianOK Il a sa juste part: cvedetails.com/vulnerability-list/vendor_id-10210/…

— base

14

@Basic welll ... ce partage est assez mince: 25 sur toutes les versions de python (4% code exec): cvedetails.com/product/18230/Python-Python.html?vendor_id=10210 vs php avec 408 (27% code exec ): cvedetails.com/product/128/PHP-PHP.html?vendor_id=74 ou Java avec 438 (3% code exec): cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 ... Donc, par «sa juste part», vous devez avoir voulu dire une «part remarquablement faible». En outre, toutes ces vulnérabilités sauf 3 étaient également des vulnérabilités dans une version 3.x et toutes les versions à jour sont corrigées.

— dhj le

2

@Basic avez-vous une meilleure suggestion pour une ligne de base de sécurité?

— dhj le

2

@dhj Oui ... Pas Java! Ok, c'est injuste. Blague / désinvolture à part, la réponse honnête est non, je ne le fais pas. C'est pourquoi je suis allé avec «juste part». Il n'y a pas de langage qui n'ait pas de vulnérabilités connues (et inconnues). Je dirais qu'en règle générale, plus un langage est utilisé, plus les vulnérabilités sont connues, uniquement en fonction de l'examen minutieux, c'est-à-dire de l'utilisation / récompense de l'exploitation. Je ne dis pas que Python est pire que les autres langages du point de vue de la sécurité, mais ce n'est pas mieux non plus. La seule vraie réponse est de programmer de manière défensive et d'avoir une sécurité en profondeur.

— base

29

En mai 2010, Word of God était que les versions de patchlevel pour Python 2.7 seraient probablement faites pendant au moins 6 ans .

Alors, peut-être 2016, probablement plus tard.

Edit: repoussé à 2020. Voir la révision de PEP 373, liée à dans d'autres réponses.

— Frédéric Hamidi
source

2

Pour tous ceux qui trouveront cette réponse à l'avenir, comme annoncé par le BDFL lui-même à PyCon 2014, la maintenance 2.7 est maintenant prolongée jusqu'en 2020.

— Silas Ray

23

Récemment, cette date a été mise à jour au 1er janvier 2020.

voir https://pythonclock.org/

— Raymond
source

15

vous devriez lire ceci attentivement (réf: https://news.ycombinator.com/item?id=7582300 ):

Il y a beaucoup de commentaires ici de personnes qui ne sont pas sur la liste python-dev et qui ne comprennent pas vraiment ce que signifie réellement cette différence. Les développeurs principaux ne sont pas tenus de maintenir 2.7 après 2015 et la plupart d'entre eux n'y seront pas impliqués. Cette partie n'a pas changé. Ce qui se passe, c'est que Red Hat se prépare à couper une version de RHEL 7, qui AFAIK dépend du montant que vous leur payez, ils supportent pendant 13 ans. Ils devront donc trouver comment prendre en charge 2.7 eux-mêmes au moins jusqu'en 2027. Voici où je lis entre les lignes. Les RH ont tout à fait le droit de bifurquer Python et de conserver leurs correctifs de maintenance pour eux et leurs clients (Python n'est pas copyleft). Mais, ce sont des gars sympas et donc peut-être qu'ils sont prêts à en amont leurs changements au moins pendant un certain temps s'il y a encore un projet Python prêt à les accepter. Encore une fois, c'est ma spéculation basée sur la discussion sur le ML, et non sur ce que RH a réellement dit qu'il ferait. Une analogie peut être faite avec Rails LTS, un fork commercial de Rails 2.x dans lequel patio11 était impliqué [0]. Inévitablement, quelqu'un va intervenir pour prendre en charge 2.7, et voyons donc ce que nous pouvons faire pour éviter une situation où le seul moyen de continuer à exécuter 2.7 est de s'abonner à RHEL. Pendant ce temps, il y a quelques grandes entreprises qui utilisent intensivement 2.7 sur Windows (par exemple Enthought, Anaconda) et on pense que quelqu'un peut probablement être trouvé pour produire un programme d'installation Windows de temps en temps, en supposant que Python.org hébergera toujours un téléchargement. Donc ce qui se passe vraiment ici n'est pas très excitant. Les principaux committers ne font rien de différent que de laisser le projet comme initialement prévu. Ce qui se passe, c'est qu'ils laisseront les lumières allumées dans le référentiel de contrôle de source et sur le serveur FTP, afin de capturer la main-d'œuvre gratuite des personnes des grandes entreprises qui ont intérêt à continuer à soutenir 2.7. L'alternative est que RH et d'autres fournisseurs créent des fourches propriétaires et coûteuses de Python 2.7. Cela peut finir par se produire de toute façon, mais il faudra plus de temps à votre employeur pour remarquer que vous devez arrêter de fournir vos correctifs si les binaires apparaissent toujours sur python.org et que vous n'avez pas à demander au service informatique de configurer SCM et un outil de suivi des bogues, etc. Ce qui se passe, c'est qu'ils laisseront les lumières allumées dans le référentiel de contrôle de source et sur le serveur FTP, afin de capturer la main-d'œuvre gratuite des personnes des grandes entreprises qui ont intérêt à continuer à soutenir 2.7. L'alternative est que RH et d'autres fournisseurs créent des fourches propriétaires et coûteuses de Python 2.7. Cela peut finir par se produire de toute façon, mais il faudra plus de temps à votre employeur pour remarquer que vous devez arrêter de fournir vos correctifs si les binaires apparaissent toujours sur python.org et que vous n'avez pas à demander au service informatique de configurer SCM et un outil de suivi des bogues, etc. Ce qui se passe, c'est qu'ils laisseront les lumières allumées dans le référentiel de contrôle de source et sur le serveur FTP, afin de capturer la main-d'œuvre gratuite des personnes des grandes entreprises qui ont intérêt à continuer à soutenir 2.7. L'alternative est que RH et d'autres fournisseurs créent des fourches propriétaires et coûteuses de Python 2.7. Cela peut finir par se produire de toute façon, mais il faudra plus de temps à votre employeur pour remarquer que vous devez arrêter de fournir vos correctifs si les binaires apparaissent toujours sur python.org et que vous n'avez pas à demander au service informatique de configurer SCM et un outil de suivi des bogues, etc.

— Navid Rahimi
source

10

Cet article dit: «Lorsque la version 2.7 sera publiée, la ligne 2.x passera à cinq ans d'un mode de correction de bogue uniquement.»

Donc, pour autant que je sache, Python 2.7 était la dernière version à ajouter des fonctionnalités 2.x, et bien que les bogues trouvés vont être corrigés (pendant un certain temps), les nouvelles fonctionnalités ne vont qu'aux versions 3.x.

— Arseny
source

3

Cet article prétend également que Python 3 introduit Unicode, donc je prendrais tout ce qu'il dit avec un grain de sel. Mais remplacez «cinq ans» par «au moins cinq ans» et c'est correct.

— Lennart Regebro le

7

Il y a aussi un compte à rebours assez inquiétant pour l'EOS à 2020.

— npit
source

6

PEP 373 (Python 2.7 Release Schedule) est la source officielle du type d'informations que vous avez demandé.

Il indique actuellement "Dates de sortie futures prévues:"

2.7.7 mai 2014
2.7.8 novembre 2014
2.7.9 mai 2015
au-delà de cette date, libère au besoin

En outre, il indique que "La date de fin de vie (EOL, date de fin de vie) pour Python 2.7 a été déplacée de cinq ans dans le futur, à 2020."

Édité en avril 2014, d'après http://hg.python.org/peps/rev/76d43e52d978

— Dr Jan-Philip Gehrcke
source

quel soulagement! j'espère que python 3 sera mort d'ici là ou renommé en quelque chose comme morella pour arrêter la confusion.

— lowtech

2

@lowtech - Ils sont peut-être passés à Python 4 d'ici là (éventuellement en introduisant de nouveaux changements incompatibles vers l'arrière), mais je ne m'attends pas à ce que 3 se soit éteint. Sur la base de la rapidité avec laquelle 3 a gagné en popularité au cours des dernières années, je pense que la communauté aura plus de personnes qui utiliseront 3 que 2 d'ici 2020. Je m'accroche toujours à Python 2, cependant ... pas assez de changements convaincants à apporter le risque de sauter à 3. J'importe beaucoup du futur , cependant.

— ArtOfWarfare

6

Le Guide du développeur Python répertorie le " Statut des branches Python " de la version 2.6 à la version actuelle, y compris leur statut de support actuel avec les dates de fin de vie.

Actuellement pris en charge (bug + correctifs de sécurité):

Python 3.8 (branche maître / développement actuelle)
Python 3.7
Python 3.6
Python 2.7 (jusqu'au 01/01/2020)

Correctifs de sécurité uniquement:

Python 3.5
Python 3.4

— chrki
source

1

Python 2.7 existera pour toujours. Il y a trop de vieux code qui l'utilise que personne ne veut réécrire. Il existe déjà une fourchette appelée Tauthon, mais nous pourrions en voir d'autres si cette échéance inutile se concrétise.

— Max
source

2

Ce n'est pas "inutile" pour les produits EOL, c'est une question d'allocation de ressources. Bien sûr, comme il est open source, il restera pour toujours dans sa forme actuelle. Mais il ne sera plus pris en charge . Au moins par les responsables officiels. Je ne sais pas vraiment à quelle question vous répondez ici.

— deceze

L'utilisateur a demandé combien de temps il y aura support pour Python2.7. L'utilisateur n'a pas demandé l'assistance des responsables officiels. Avec un projet comme celui-ci, avec autant de lignes de code là-bas, dans la pratique, il y aura des mises à jour régulières, des backports et un bon support pour Python2 pour toujours, par des non-responsables. (J'ai été emporté par ma frustration personnelle à propos de tout ce truc Python3, d'où le "inutile").

— Max

Je pense que ce commentaire est pertinent. Tauthon est identique à Python 2.7 et semble être supporté pendant un certain temps. Donc, cela vaut la peine d'être mentionné.

— Phil

J'ai fait l'expérience que les jeunes programmeurs ne comprennent pas la puissance et l'efficacité qui découlent de la garantie d'une compatibilité ascendante. Je ne comprendrai jamais la décision de Guide van Rossum de causer du tort, plus de dizaines de milliers d'heures de vie gaspillée, en rompant intentionnellement la compatibilité sans aucun avantage positif (ni performances ni lisibilité).

— Max

1

@Tetragrammaton: Veuillez expliquer pourquoi ne pas être compatible est une bonne chose. Veuillez expliquer ce que serait le "défaut fondamental". Je travaille avec Python à plein temps depuis plus de 15 ans et je ne vois pas de différence majeure qui me concerne. C est resté le même pendant 40 ans et est toujours une langue majeure et n'a pas beaucoup changé. Javascript s'est considérablement amélioré au fil des ans et est toujours rétrocompatible. C ++ est toujours rétrocompatible avec C. Windows 10 peut toujours exécuter des programmes Windows 3. Nos processeurs exécutent toujours du code 8086 des années 70. Nous progressons chaque jour, sans rompre le support.

— Max