Cela fait environ 10 jours cette année. En même temps que la fin des années 2010, une ère se terminera dans le monde de Python. Python 2.7, qui est supporté depuis longtemps, prendra fin le 1er janvier 2020 (EOL: End of Life). En d'autres termes, après cela, même si un bogue est trouvé, une version corrigée ne sera pas publiée. Python 2.7 sera le dernier de la série 2 et Python 2 prendra sa retraite.
La première version de Python 2.7 est sortie le 3 juillet 2010, donc je suis actif depuis neuf ans et demi. Python 3 à l'époque était la version 3.1. À partir de là, le nombre de versions a atteint 3,8 et le nombre de versions mineures a dépassé Python2.
Au cours des 20 ans d'histoire de Python2, 2.7 représentait la moitié de cela, ce qui était une situation inhabituelle car Python3 était incompatible avec Python2 et mettait beaucoup de temps à migrer. Python 2.8 n'était pas censé sortir comme déclaré dans PEP-404, il reste donc Python 2.7 J'ai continué à tirer. En fait, ma première retraite remonte à 2015, mais même en 2014, la transition ne progressait pas du tout, et j'ai reporté l'EOL de cinq ans parce que j'ai dit «ce n'est pas bon».
Au départ, Python3 avait des problèmes de performances, et j'étais l'un de ceux qui sont restés longtemps avec Python2. Au fil du temps, ces problèmes ont été progressivement résolus et les utilisateurs n'ont commencé à migrer que lorsque des bibliothèques bien connues sont devenues compatibles Python 3. Il n'est pas difficile d'imaginer les difficultés de ceux qui ont réussi à prendre leur retraite en 10 ans, mais on m'a rappelé que même si c'est bien, les gens ne déménageront que si les avantages de la transition dépassent les coûts associés à la transition. Je vais.
La fin du support de Python 2 ne signifie pas qu'il sera indisponible immédiatement. Par contre, même s'il y a des bugs ou des problèmes de sécurité, il n'est pas possible d'utiliser un logiciel qui n'est pas mis à jour pour un usage commercial, et même s'il n'est pas commercial, il y a la même possibilité de dommage, donc le passage à Python 3 n'a pas attendu Je pense.
Je pense que beaucoup de gens disent que le Python qu'ils utilisent est déjà la version 3, mais une chose qui est souvent négligée est lorsqu'ils sont utilisés indirectement. Si de nombreux outils s'appuient sur Python et que vous les avez installés, par exemple via Package Manager, vous pouvez extraire Python2. Par exemple, node.js et vim, qui ne semblent pas liés à première vue, utilisent également python. Par conséquent, les administrateurs de chaque gestionnaire de packages travaillent dur pour déplacer les packages qui dépendent de Python2 vers Python3. J'ai étudié la situation concernant Homebrew et Debian, alors j'aimerais en parler.
Homebrew
Dans Homebrew, le package python fait référence à python3 et python2 est fourni sous le nom du package python @ 2. Ce paquet python @ 2 devrait être effacé au début de la nouvelle année comme ceci Pull Request a déjà été émis. Cependant, certains packages en dépendent encore et doivent être résolus en premier. Il y a un problème pour cela sur ici, mais quand je le regarde, certains paquets ne sont toujours pas pris en charge.
Si vous vérifiez la situation actuelle, cela ressemblera à ceci.
$ brew uses python@2
git-remote-hg ipython@5 mysql-utilities pwntools terminator
headphones mkvtomp4 offlineimap pygobject volatility
hg-flow molecule ooniprobe redo vte
Si vous voulez savoir si l'un de ceux-ci inclut ce que vous avez installé, essayez brew uses --installed python @ 2. J'avais installé mysql-utilities. Apparemment, il n'y a plus de mises à jour, et ici suggère que vous êtes encouragé à passer au shell MySQL, alors j'aimerais l'essayer.
De plus, le python standard de MacOS semble être 2.7, même dans la dernière Catalina. Cependant, lorsque je le lance, le message "Je ne recommande pas d'utiliser Python 2.7!" Apparaît. On dit qu'il sera effacé dans le futur, mais je me demande s'il restera tel quel jusqu'à la sortie de la prochaine version.
Debian
Debian essaie également de supprimer Python2. Cependant, Debian a une longue histoire et un grand nombre de paquets, ce qui complique les choses. Les paquets affectés par la suppression de Python2 sont enregistrés dans le système de gestion des bogues de Debian et sont marqués comme py2removal (Bugs tagged py2removal. .cgi? tag = py2removal; users = [email protected])), le nombre total est de 3,443. Parmi ceux-ci, 1 960 ont été résolus. Les 1 483 paquets restants sont toujours ouverts.
Ceux qui sont rarement utilisés ou qui n'ont pas été maintenus en amont (développeur) sont sujets à effacement, et beaucoup ont déjà été effacés. Ainsi, les 1 500 paquets restants contiennent des éléments importants. En particulier, il y en a plus de 600 qui sont considérés comme "graves" (les plus graves), et python2 ne sera probablement pas effacé à moins que ceux-ci ne soient résolus. Il n'y a pas d'autre choix que de regarder la tendance combien de temps cela prendra.
Un rapide coup d'œil sur la liste ouverte révèle des noms familiers. Par exemple, «trac». Il s'agit d'un outil de gestion de tickets, pour ainsi dire, une version Python de redmine. J'avais l'habitude de l'utiliser il y a longtemps, mais j'ai entendu le nom après un long moment. En amont, une nouvelle version (1.4) est sortie en août de cette année, mais elle n'est pas encore compatible avec python3. En regardant la feuille de route, il semble qu'elle sera prise en charge dans le prochain 1.6, mais ce n'est pas du tout à temps. Le développement de Trac lui-même se fait sur Trac https://trac.edgewall.org/wiki, mais je ne peux pas nier qu'il est vieux. Je pensais que ce serait plus facile si je le faisais sur Github, mais la signification de ce Trac serait perdue en premier lieu (rires). Après tout, cela me fait réaliser que les logiciels ont également une durée de vie limitée.
De plus, la communication avec chaque responsable de paquet est répertoriée dans le ticket de bogue, mais elle est assez violente. Par exemple, Ticket pour un paquet appelé Calibre dit: "Vous ne pouvez rien faire du tout." "Ne dispersez pas le FUD (peur, anxiété, doute)" ou quelque chose d'assez fort. C'est un travail inutile qui ne serait pas fait si Python2 pouvait être utilisé tel quel, donc je ne suis pas sûr, mais cela ressemble aux avantages et aux inconvénients de laisser Python2 en parallèle avec Python3 pendant longtemps.
Qu'arrivera-t-il à Python 2.7 après janvier? En fait, PEP-373 a un calendrier de publication dans le futur.
--2.7.18 Code Freeze ... Janvier 2020 --2.7.18 Release candidate ... Début avril 2020 --2.7.18 Sortie officielle ... mi-avril 2020
Je pensais que cela n'avait pas été arrêté en janvier, mais il semble qu'il n'y ait qu'une seule dernière version de maintenance. Homebrew abandonnera plus Python @ 2, donc le prochain 2.7.18 pourrait être une version fantôme.
J'ai vérifié l'état de préparation de Homebrew et Debian en raison du retrait de Python2. Je voudrais garder un œil sur ce qui se passe réellement après cela.
Vous pouvez voir le compte à rebours avant la retraite sur https://pythonclock.org/.
Recommended Posts