Pour cette rentrée 2019, faisons le point sur Python : actualité, bonnes pratiques, astuces, projets intéressants, témoignages…
Cette partie 2 traite de Python 2. 🐍 🐍 Oui, c’est la fin de la maintenance de Python 2. Joie pour certain, désolation pour d’autres…
Allez, on se raconte toutes nos anecdotes dans les commentaires.
Sommaire
- Licence
- Rendre un script exécutable
- j − 100 avant la fin de Python 2
- Et toi, comment vis tu cette fin de Python 2 ?
Licence
Cette dépêche est publiée sous licence CC0 (sous domaine publique dans les pays où cela est possible) pour te permettre de recopier, modifier, réutiliser et republier ce contenu sans t’obliger à citer ses auteurs (sauf que la loi de certains pays comme la France t’oblige quand même à citer les auteurs).
Rendre un script exécutable
Pour lancer un script Python, de nombreuses personnes font :
python3 script.py
Avec deux petits changements, il est possible de le lancer juste comme ça :
./mon-script.py
Premier changement, dire que le script est un fichier e*X*écutable :
chmod +x mon-script.py
Second changement, on rajoute un shebang sur la première ligne du fichier mon-script.py
:
-
pas bien 😯 :
#!/usr/bin/python
-
pas bien 🤔 :
#!/usr/bin/python3
-
très bien 😛 :
#!/usr/bin/env python3
Les deux premiers caractères du fichier « #!
» sont appelés le shebang, et même des langages dont le croisillon « #
» n’est pas utilisé pour les commentaires le prennent en charge, comme PHP.
Le /usr/bin/env
.
j − 100 avant la fin de Python 2
La durée de maintenance d’une version Python est généralement de cinq ans.
Mais Python 2.7 (2010) bénéficie d’une durée de maintenance étendue, jusqu’au 1er janvier 2020. C’est la version de Python ayant la plus grande durée de maintenance, ce qui explique aussi le fait que de nombreuses organisations se soient concentrées sur d’autres problématiques plus urgentes, et par procrastination, Python 2 est encore utilisé en 2019 !
Si tu dois maintenir du code compatible Python 2.6 (2008) ou 2.7 (2010), ce chapitre est fait pour toi. Si tu dois maintenir une compatibilité avec Python 2.4 (2004), tu peux regarder comment le projet Ansible s’y prend prenait. Le code source d’Ansible 2.3, la dernière version compatible Python 2.4, est disponible dans la branche stable-2.3 (GitHub).
Mort du projet utilisant Python 2
Si le code compatible Python 2 est prévu pour être remplacé par autre chose dans un avenir proche, le conseil : sois fainéant, fais le strict minimum, et aide plutôt à faire avancer le projet qui doit remplacer le vieux code Python 2.
Tu peux quand même remplacer python
par python2
pour explicitement indiquer que c’est seulement compatible Python 2. Par exemple, en haut de tes scripts *.py
remplace le shebang :
-
pas bien 😯 :
#!/usr/bin/python
-
pas bien 🤔 :
#!/usr/bin/env python
-
très bien 😛
#!/usr/bin/env python2
Les versions des grandes distributions GNU/Linux qui sortent pour cette fin d’année, devraient avoir la commande python
qui correspond à Python 3. Que ce soit Debian, Arch Linux, Ubuntu, Fedora, openSUSE, etc., toutes auront (enfin) migré leurs scripts vers Python 3. Les rares scripts qui nécessitent encore Python 2 appelleront explicitement python2
et non pas python
.
Nouveau code compatible Python 2 et 3
Si tu écris du nouveau code qui doit être compatible à la fois Python 2 et 3, alors ajoute en haut de ton nouveau fichier *.py
les lignes suivantes :
from __future__ import absolute_import
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals
from builtins import *
from future import standard_library
standard_library.install_aliases()
⚠ Attention, ne pas le faire sur ta base de vieux code Python 2 ⚠
Le top est d’avoir ces lignes dans tous tes fichiers *.py
. En plus de devoir adapter le code source, de nouveaux bogues peuvent apparaître. Par exemple, la ligne from __future__ import division
change le résultat de x = 1 / 2
:
$ python2
Python 2.7.16
>>> 1 / 2
0
>>> from __future__ import division
>>> 1 / 2
0.5
Ctrl
+ D
$ python3
Python 3.7.3
>>> 1 / 2
0.5
Si tu testes du code en mode interactif, comme dans l’exemple python2
ci‐dessus ou avec ipython
, pense à taper tous ces import
avant de tester ton code pour être sûr d’avoir le même comportement. Pour ne pas avoir à taper ces lignes à chaque fois, tu peux les mettre dans le script d’initialisation, comme sur cet exemple :
$ cat ~/.ipython/profile_default/startup/ipython_config.py
from __future__ import absolute_import
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals
from builtins import *
from future import standard_library
standard_library.install_aliases()
Attention à ne pas s’emmêler les pinceaux en voulant tester du code Python 2 only et du code compatible avec les deux versions !
Autre détail : le shebang. Comme dit plus haut, la commande python
devrait correspondre à Python 3 avec la sortie des nouvelles versions Debian, Arch Linux (publication continue), Ubuntu, Fedora, openSUSE.
Si ton script pourrait être exécuté sur une machine ayant seulement Python 2 :
#!/usr/bin/env python
# Ce script est compatible Python 2 et 3
# Ce script doit pouvoir être exécuté sur une machine ayant seulement Python 2
Sinon :
#!/usr/bin/env python3
# Ce script est compatible Python 2 et 3
# Ce script est toujours exécuté sur une machine ayant Python 3
Migration vers Python 3
Il existe déjà beaucoup d’articles sur le sujet, voici quelques liens :
- article de janvier 2019 (en français) ;
- migration assistée avec
2to3
(en français) ; - documentation officielle (en anglais).
Migration vers Go
Google utilisait pas mal d’applications Python 2.7 pour gérer la partie serveur de certains de ses sites Web (comme YouTube). Sa décision a été de migrer vers Go. Google a publié en 2017, son script de migration transpilation :
https://github.com/google/grumpy
Et toi, comment vis tu cette fin de Python 2 ?
- enfin, on aura plus à gérer la rétrocompatibilité ? 🤩
- sniff, on avait enfin une version stable de Python ? 💚 💚
Tes conseils pour gérer la transition ?
Et n’oublie pas de nous donner un coup de main pour la troisième partie de cette série de dépêches :
→ https://linuxfr.org/news/python-pour-la-rentree-2019-partie-3
Aller plus loin
- Python — partie 1 ― Popularité (372 clics)
- Python — partie 3 — Installation de Python et de paquets (35 clics)
- Python — partie 4 — Py Pyenv (8 clics)
- Python — partie 5 — Nix (et Guix) (6 clics)
- Python — partie 6 — Pip et Pipx (4 clics)
- Python — partie 7 — Environnements virtuels (4 clics)
- Python— partie 8 — Pipenv (3 clics)
- Python ― partie 9 ― Formateur de code, analyse statique (10 clics)
- Python — partie 10 — Entretiens (3 clics)
# Propagande /usr/bin/env ?
Posté par haleth . Évalué à 3.
https://unix.stackexchange.com/a/29620
Peut-on avoir un peu d'argument en faveur de ce qui est quand même une grosse partie de l'article ?
Ou sommes-nous supposés l'accepter comme la bonne parole .. ?
[^] # Re: Propagande /usr/bin/env ?
Posté par raphj . Évalué à 9. Dernière modification le 08 septembre 2019 à 22:49.
Discussion connexe en mai : https://linuxfr.org/users/raphj/journaux/shebang-usr-bin-env-sh-teste-et-approuve
Pour répondre directement à ta question : si j'ai un autre Python dans mon
$PATH
que celui du système, c'est probablement que j'ai envie que ça soit celui-là qui soit utilisé. En tant qu'utilisateur simple sur une machine, c'est d'ailleurs ma seule manière de choisir l'interpréteur Python à utiliser.Je connais très peu les environnement virtuels Python (virtual env) mais ils sont relativement répandus et je suppose que le shebang peut avoir un impact sur leur bon fonctionnement.
Argument d'autorité : si c'est ce qui est préconisé par les concepteurs du langage eux-même, c'est que ça ne doit pas être trop mal non plus et par défaut, j'aurais tendance à suivre le conseil.
Dans le lien que tu donnes, la personne pointe un désavantage : c'est qu'on ne peut pas passer d'argument à l'interpréteur. Mais en Python, on s'en fiche un peu. L'autre désavantage pointé c'est le fait qu'un script Python peut se comporter différemment selon l'utilisateur qui lance le script parce qu'il aura peut-être un autre interpréteur, mais je dirais que c'est une fonctionnalité plus qu'un bogue. D'ailleurs la personne présente ce comportement aussi comme un avantage…
Sinon, quand j'utilise Termux sous Android, Python n'est pas à l'emplacement
/usr/bin/python
.env
non plus n'est pas à l'emplacement/usr/bin/env
, mais un mécanisme est en place pour contourner ça pourenv
. Termux n'est probablement pas le seul environnement comme ça.Au final, concrètement, je ne vois que des avantages à utiliser
#!/usr/bin/env
et je trouve que parler de propagande puis demander des arguments, c'est un peu étrange. Est-ce qu'il faudrait justifier toutes les bonnes pratiques / pratiques usuelles au cas où quelqu'un les remette en cause ? Non, je ne pense pas : à la personne qui souhaite les remettre en cause d'argumenter ! (et je suis souvent cette personne…)(je ne t'ai pas moinsé)
[^] # Re: Propagande /usr/bin/env ?
Posté par haleth . Évalué à 4.
Merci pour cette réponse étrangement complémentaire à l'article
[^] # Re: Propagande /usr/bin/env ?
Posté par harlock974 . Évalué à 1.
Je n'ai pas très bien compris pourquoi
#!/usr/bin/env python3
est mieux que#!/usr/bin/python3
.C'est juste au cas où
python3
ne serait pas dans/usr/bin/
, pour des questions de portabilité ?Mais, à part l'exemple très particulier d'Android,
env
est-il toujours sous/usr/bin/
?[^] # Re: Propagande /usr/bin/env ?
Posté par barmic 🦦 . Évalué à 2.
Comme il le dit, ceux qui installent
env
ailleurs que dans/usr/bin
vont mettre en place un hack pour que le shabang fonctionne. Du coup il n'ont pas à le faire aussi pourbash
,awk
,perl
,ruby
,python
,…https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Propagande /usr/bin/env ?
Posté par raphj . Évalué à 9. Dernière modification le 09 septembre 2019 à 09:24.
Supposons que tu doives utiliser sur une machine où Python 3 n'est pas installé (ou alors, c'est une ancienne version et tu dois utiliser une nouvelle version), et tu n'es pas root.
Tu installes Python dans ton home et tu le places dans le
$PATH
.#!/usr/bin/env python3
va marcher, et pas#!/usr/bin/python3
.[^] # Re: Propagande /usr/bin/env ?
Posté par anaseto . Évalué à 5. Dernière modification le 09 septembre 2019 à 15:55.
C'est aussi le cas sous les BSDs. Dans OpenBSD on utilise
/usr/local/bin/
pour les programmes qui ne sont pas de base (comme python) et probablement sur les autres BSDs aussi, alors que/usr/bin/
n'est utilisé que pour les programmes du système de base, dontenv
fait partie.Edit : ce que j'avais écrit initialement ne voulait au final rien dire.
[^] # Re: Propagande /usr/bin/env ?
Posté par Vincent Danjean . Évalué à 1.
De mémoire, /usr/bin/env est spécifié dans la norme Unix (comportement du programme et chemin d'accès). Ce n'est pas le cas pour python. Pendant assez longtemps, ce dernier a parfois été installé manuellement (ie sans passer par une distrib) dans /usr/local. Utiliser /usr/bin/env permet de faire marcher les scripts python dans beaucoup plus de situations.
[^] # Re: Propagande /usr/bin/env ?
Posté par calandoa . Évalué à 7.
Il semblerait que ta mémoire te joue des tours car j'ai un petit peu cherché et j'ai trouvé le contraire !
La référence Posix ne spécifie aucun endroit pour placer
env
:https://pubs.opengroup.org/onlinepubs/9699919799/utilities/env.html
Le Filesystem Hierarchy Standard ne précise rien pour
env
, mais impose/usr/bin
pour Python si il est installé:http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s04.html
La Linux Standard Base ne spécifie aucun endroit pour
env
:https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/command.html#TBL-CMDS
… et déconseille même d'utiliser
env
pour lancer un script !https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#EXECUTABLE-SCRIPTS
Par ailleurs, utiliser un argument avec python est parfois utile, je me rappelle que
-u
m'a sauvé la vie qq fois.Au final je ne veux pas imposer un quelconque usage, il semble que pour les BSD passer par
env
soit plus fonctionnel, mais c'est assez amusant de voir des gens vindicatifs imposer leur pratiques, et ce en contradiction avec les standards existants ![^] # Re: Propagande /usr/bin/env ?
Posté par raphj . Évalué à 9. Dernière modification le 10 septembre 2019 à 13:41.
J'imagine que pour les outils systèmes, il vaut mieux utiliser
/usr/bin/python3
plutôt que/usr/bin/env python
, parce que ces outils devraient certainement tourner avec l'interpréteur python du système.D'ailleurs, c'est intéressant de faire un
grep /usr/bin/python *
et ungrep /usr/bin/env python *
dans/usr/bin
.Pour les scripts non systèmes, le problème est un peu différent et le commentaire déconseillant d'utiliser
/usr/bin/env
le fait parce qu'on risque de se retrouver à un interpréteur différent, mais avoir ce "risque" me semble justement intéressant d'autant qu'/usr/bin/python
est optionnel, justement et que/usr/bin/python2
et/usr/bin/python3
ne sont même pas mentionnés. À noter aussi que cette remarque ne fait, je pense, pas partie du standard, mais est informative, donc conseiller l'inverse ne rentre pas vraiment en contradiction avec les standards existant.Je dirais aussi que la LSB définit bien la position de
env
, en définissant son existence, puis en précisant : "This is the primary directory of executable commands on the system." dans le chapitre parlant de/usr/bin/
.Par contre je me rends effectivement compte qu'il n'est pas clair que Python suggère spécifiquement d'utiliser
/usr/bin/env
.Sérieux, tu as vu des gens vindicatifs imposer leur pratiques ici ? Moi j'ai vu des gens discuter calmement sur le problème, exposer leur avis, peut-être se tromper. Après la mention de la "propagande", on lit "vindicatif", "imposer". Vous vous rendez compte de la définition et de la force des mots que vous employez ? Je n'ai vu personne imposer quoi que ce soit.
[^] # Re: Propagande /usr/bin/env ?
Posté par raphj . Évalué à 3.
Précision et correction: L'existence de
env
est défini par la LSB et/usr/bin/
est défini par le FHS.(du coup, j'en profite aussi pour corriger
grep /usr/bin/env python *
: je voulais diregrep "/usr/bin/env python" *
)[^] # Re: Propagande /usr/bin/env ?
Posté par barmic 🦦 . Évalué à 0.
/usr/bin/python2
ne devrait pas exister. python c'est python 2 et ce ne sera jamais python 3.Il reste qu'à savoir si
env
doit être dans dans le premier dossier des exécutables.Système ? Je sais pas trop ce que c'est qu'un outil système, mais oui tout scripts installé par ton gestionnaire de paquet devrait s'assurer d'utiliser l'implémentation du système et de ne pas avoir un fonctionnement distinct en fonction de l'environnement de l'utilisateur. C'est une aide importante pour les développeurs. Si tu utilise une version quelconque de python (une version de développement, un build perso,…), tu veux pouvoir l'utiliser pour ton travail sans que ton client mail explose en vole parce qu'il a le malheur d'être lui aussi écris en python.
Ça fait du coup bien parti de ses patchs que les distributions pourraient appliquer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Propagande /usr/bin/env ?
Posté par raphj . Évalué à 5.
Mmm, la PEP 0394 n'est pas si franche à ce sujet.
Oui, je parlai de ça :-)
[^] # Re: Propagande /usr/bin/env ?
Posté par calandoa . Évalué à 1.
J'avoue, après vérification, « vindicatif » n'est pas du tout pertinent, car il exprime l'idée de rancune. Je voulais en fait dire « opiniâtre », et pas par rapport à ton message, mais par rapport au journal qui te dit très clairement « ceci est bien », « ceci est mal », alors que c'est du grand n'importe quoi. Cette histoire de
#!/usr/bin/env
, c'est juste un simple workaround permettant apparemment de faire tourner out of the box les mêmes scripts sur Linux et BSD, mais déconseillé par le standard.Bon par contre, même si tes messages sont intéressants, je viens de voir que le journal en lien pour
sh
est de toi, et là, désolé, mais c'est vraiment n'importe quoi… mais j'imagine que c'était du hacking humoristique.Pour répondre plus précisément à ton message, le FHS ne suggère pas du tout de mettre
env
dans/usr/bin
: si tu lis la page de/bin
, tu trouves aussi : « It may also contain commands which are used indirectly by scripts », donc on peut en déduire qu'on ne peut rien en déduire…Par contre Python recommande l'usage de
env
:https://docs.python.org/3/using/unix.html !
[^] # Re: Propagande /usr/bin/env ?
Posté par raphj . Évalué à 4. Dernière modification le 10 septembre 2019 à 17:19.
Mhmm, non, j'étais plutôt sérieux, mais ça a l'air de diviser, à voir les retours qu'il y a eu sur ce journal. À vrai dire, je découvre avec surprise qu'utiliser
/usr/bin/env
ne va pas de soi. Je suis maintenant persuadé que tout ce qui est fourni par la distribution ne devrait pas utiliser/usr/bin/env
, mais je suis assez persuadé que le reste devrait le faire.C'est étrange que l'endroit où
env
devrait se trouver n'est pas plus spécifié que ça. Ça m'intéresserait de savoir pourquoi. En tout cas, dans les distributions GNU/Linux et BSD classiques,env
semble être toujours dans/usr/bin
, donc c'est certainement au moins un standard de fait que les gens ont l'air de respecter. Et sous Debian,/bin
pointe vers/usr/bin
, sous Fedora aussi je crois, et pas sous openSUSE. Je ne serais pas étonné que dans quelques temps, tout le monde fasse ça et que la position deenv
sera de toute façon bien spécifiée à cause de cette fusion. Cf https://unix.stackexchange.com/questions/5915/difference-between-bin-and-usr-bin/60135#60135[^] # Re: Propagande /usr/bin/env ?
Posté par jihele . Évalué à 3.
Quand j'ai commencé à utiliser virtualenv, j'étais embêter pour faire tourner le pylint de ma distro pour cette raison (il utilisait Python2 par défaut et mes venvs étaient en Python 3).
SO: pylint doesn't point to virtualenv python.
J'avais naïvement demandé au mainteneur d'utiliser /usr/bin/env et je m'étais fait jeter. Il avait sans doute raison.
Maintenant, j'installe pylint via pip dans mes venv (automatiquement à la création du venv, avec flake8 et peut-être d'autres trucs) et je pense que c'est la bonne méthode.
[^] # Re: Propagande /usr/bin/env ?
Posté par Anonyme . Évalué à 1.
C’est le cas sur Alpine aussi.
Mais bon, ça reste suffisamment anecdotique pour pas s’embêter avec ça.
[^] # Re: Propagande /usr/bin/env ?
Posté par raphj . Évalué à 3. Dernière modification le 10 septembre 2019 à 13:45.
D'ailleurs je me demande si l'intention initiale n'était pas d'aborder ce point, parce qu'il y a un "Le
/usr/bin/env
." qui traîne en plein milieu de la dépêche.Une petite correction ?
[^] # Re: Propagande /usr/bin/env ?
Posté par Oliver (site web personnel) . Évalué à 2.
Oui, mon intention était d’expliquer les avantages d’utiliser
#!/usr/bin/env python{2|3}
dans ses propres scripts et pourquoi les scripts systèmes utilisent plutôt#!/usr/bin/python{2|3}
Et puis, j’ai dû faire un autre truc (context switching) et j’ai zappé la rédaction de ce paragraphe. 😬 Et quand j’ai relu rapidement la dépêche avant de la soumettre, je n’ai pas remarqué ce paragraphe à peine entamé. 😵
Merci pour les commentaires sur ce sujet, je ne connaissais pas précisément ce que recommandaient les différents standards. Merci raphj pour ta perspicacité. 😊
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
# Stratégies de migration
Posté par flan (site web personnel) . Évalué à 3.
Il aurait pu être pas mal de plus expliciter les deux grandes stratégies possibles pour la migration :
- rendre du code Python 2 compatible avec Python 3,
- rendre du code Python 3 compatible avec Python 2.
Bien sûr, on peut faire le 1) puis le 2), pour finir par se débarrasser de Python 2.
Le 2) est plus facile car Python 3 est plus strict que Python 2 et une bonne partie du travail est faisable automatiquement.
Souvent, la partie compliqué est de savoir convertir les str de Python 2, qui deviennent soit des bytes, soit des str en Python 3 (et parfois l'un ou l'autre en fonction de leur valeur…). Au contraire, les str de Python 3 deviennent en Python 2 des unicode et les bytes deviennent des str : pas de question à se poser.
# Pas trop tôt
Posté par Olivier . Évalué à 10.
En poussant un soupir de soulagement. Le même genre de soupir qu’en voyant Flash disparaître des navigateurs. Une vieillerie de moins !
C’était une erreur d’accorder un délai de 10 ans pour Python 2. Ça n’a servi à rien à part encourager à procrastiner. Surtout que la migration n’était quand même pas bien compliquée.
J’espère que la fondation Python ne refera plus la même erreur. J’ose croire que c’est pour cette raison qu’ils ont ajouté async et await sur une version dite “mineure” (la 3.7) : pour éviter la fossilisation qu’on a connue avec Python 2. Les changements progressifs encouragent les dévs à ne pas se crisper sur une version.
Aucun. Fallait migrer il y a longtemps. Genre il y a dix ans. T’aurais eu moins de boulot. ;)
Pas gentil de ma part, mais Python 2 m’aura vraiment cassé les pieds. Vraiment content que ce truc soit enfin relégué au rang des vieilleries obsolètes.
Stable ??? Bof, buguée et pas terrible pour la gestion des chaînes de caractères et de bytes.
Je ne comprends pas qu’on puisse regretter Python 2. Mais bon, il y a bien des gens pour aimer JavaScript. On peut aussi aimer se flageller avec Python 2, j’imagine.
[^] # Re: Pas trop tôt
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Tu t'avances fort là, peut être que ça n'était pas compliqué dans ton cas, mais il y a des cas où c'était franchement pas simple (Twisted et Mercurial par exemple). Il faut noter aussi qu'il y a des améliorations arrivées plus tard qui bloquaient des migrations auparavant (le
%
formatting sur lesbytes
par exemples, il me semble que ça a fortement aidé à la migration de Twisted), et des dépendances qui pouvaient manquer.Bien au contraire, j'ai fait la migration récemment et j'ai eu moins de boulot parce que j'ai attendu (je n'avais de toute façon pas tellement le choix). D'une part certaines dépendances n'étaient pas prêtes, et d'autre part des fonctionnalités de Python ou de la bibliothèque standard n'existaient pas ou n'étaient pas aussi complètes qu'aujourd'hui (
asyncio
par exemple, même si ça n'est pas indispensable au passage Python 3, ça simplifie de pouvoir faire ça en même temps maintenant).Il y a aussi des projets qui n'ont tout simplement pas pu être portés sur Python 3. C'est le cas de
Pyjamas
, un transpileur Python => JavaScript. On utilisait ce projet et on a dû jeter une bonne partie du code. Il y a probablement des cas similaires qui ont dû refroidir les envies de passer à Python 3 rapidement.Et bien sûr, plus on attend, plus on a de chances que les plâtres aient été essuyés.
[^] # Re: Pas trop tôt
Posté par Olivier . Évalué à 4. Dernière modification le 09 septembre 2019 à 12:51.
Mea culpa. Je veux bien croire que ça n’a pas toujours été simple pour tout le monde et que je généralise un peu vite.
Mais le problème des dépendances, c’est justement qu’on est tributaire d’autrui pour gérer ses propres problèmes, et que si les autres ne font pas leur boulot ou ne le font pas à temps ou que le projet tombe à l’eau, on est bloqué. Mais ce problème n’a rien de spécifique avec la migration en Python 3. C’est tout le temps vrai. Si les dépendances cassent, bloquent, buguent ou ne sont plus mises à jour, on se retrouve coincé, avec une pile d’adaptations à gérer, et c’est vrai dans tous les langages et en tout temps. Ce n’est pas particulièrement la faute à Python 3.
De ce dont je me souviens des discussions à l’époque, c’est que beaucoup ne voulaient tout simplement pas migrer, n’en voyaient pas l’intérêt et n’en avaient rien à faire. Beaucoup de mauvaise volonté, et le blâme est retombé sur Python 3. Si j’ai bonne mémoire, il avait été envisagé par certains de faire un fork de Python 2. Bref, le problème m’a toujours plus paru être une question communautaire qu’un problème intrinsèque au langage lui-même.
[^] # Re: Pas trop tôt
Posté par Cilyan Olowen (site web personnel) . Évalué à 2.
Il ne faut pas oublier non plus que l'API C a beaucoup changé.
Pour un petit script, voire même un gros, ça fait effectivement un bout de temps qu'on peut rendre ou créer un code compatible avec les deux versions. Pour un nouveau script, je préfère coder en Python 3 et utiliser quelques astuces pour qu'il soit compatible Python 2. Avec
six
en dernier recours (c'est pas toujours simple d'installer un module tierce dans un environnement industriel). Pour les migrations, ben on fait comme on peut.Par contre, j'ai aussi récupéré un projet de module Python 2 codé en C, un très gros bébé*, et là franchement, j'ai même pas tenté de le migrer. D'ailleurs, ça n'aurait pas eu de sens, le support de Python 2 était suffisant pour que le projet qui dépende du module se finisse avant. Donc pas besoin de migrer, juste laisser mourir.
* Pour donner une idée, c'était du Software In the Loop. On prend le logiciel tel qu'habituellement embarqué sur la plateforme, on le compile comme un module Python avec du code de glu à moitié auto-généré (un générateur maison qui fournit une entrée à SWIG), et comme ça on manipule les entrées et sorties en Python. Avec une interface NumPy pour gagner en performances. C'est beau, mais quand ça marche, on touche plus. :)
[^] # Re: Pas trop tôt
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Python 3 est une énorme amélioration et c'était une bonne chose de le faire (rien que la gestion des strings/bytes et le unicode par défaut justifie Python 3). Mais la migration n'a pas été simple, et n'avait pas nécessairement à être gérée immédiatement par tout le monde.
Comme je le dis plus haut, pour ma part je suis content d'avoir eu le support étendu et de faire la migration maintenant, j'aurais eu beaucoup plus de mal il y a quelques années, voire ça n'aurait tout simplement pas été possible (et à lire en diagonale les commentaires sur hacker news c'est le cas pour beaucoup de monde).
Aussi quand on lit que Python 3 est dispo depuis 10 ans, c'est un peu oublier que les premières versions de Python 3 étaient loin d'être parfaites, et que certaines fonctionnalités manquaient (comme les formatage avec
%
sur les bytes, que j'ai déjà mentionné plus haut).Bref, il faut aussi faire confiance au développeurs, si certains ont attendu (et j'en fait partie), il peut y avoir de bonnes raisons derrières.
[^] # Re: Pas trop tôt
Posté par Philippe F (site web personnel) . Évalué à 7.
Ha ha ha!
Dans quel monde vis-tu réellement ? En dehors de quelques geeks passionnés, la majorité des informaticiens ne s'amuse pas à changer de version pour le plaisir si ça marche déjà. C'est encore plus vrai dans le monde professionnel.
Du coup, tout le monde utilise des versions antidéluviennes et fait des grands bonds en terme de migrations.
A mon boulot, on est bloqué à Python 3.1 pour un certain nombres de logiciels, et ce n'est pas prêt de bouger: l’équipe qui les maintenait n'est plus là. Je vais avoir du mal à justifier auprès de mes chefs qu'on doit maintenir et faire évoluer un nouveau package Python qu'on connait mal, simplement parce qu'on veut utiliser une version plus récente de Python, alors même que celle qu'on utilise marche très bien.
Ce n'est que le couteau sur la gorge que ma boite envisagera cette migration…
Même des très grosses boites comme GitHub ou Dropbox, qu'on ne peut pas trop soupçonner d'être à la rue en terme de technologie ont mis beaucoup de temps pour migrer aux dernières version de Rails et Python.
Quelques lectures intéressantes : https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one-of-the-largest-python-3-migrations-ever/
J'ai pas retrouvé le blog où la mise à jour Rails était décrite mais j'ai souvenir que c'est étalé sur plus d'une année.
[^] # Re: Pas trop tôt
Posté par Olivier . Évalué à 3. Dernière modification le 09 septembre 2019 à 17:01.
Je vais reformuler ma pensée imprécise. J’ai dit:
J’aurais dû dire pour être plus précis:
Tout le monde se fout que ta boîte soit scotchée sur Python 3.1.
Tout le monde se fout qu’une autre décide de faire la moule sur Python 3.4.
Tout le monde se fout qu’une autre ne veut plus entendre parler que de Python 3.5.
Etc.
S’il y a eu blocage sur Python 2.7, c’est parce que Python 3.0 apportait trop de changements majeurs d’un coup. Ça a fâché beaucoup de monde, et ce monde a fait masse et résistance pour tenter de bloquer et retarder la migration.
Je pense que la fondation Python a retenu la leçon et ne refera plus la même erreur (du moins on peut l’espérer).
[^] # Re: Pas trop tôt
Posté par nico4nicolas . Évalué à 4.
A la vue du succès que connait le langage, était-ce vraiment une erreur ? Est-ce que les 2 versions de Python n'ont pas permis de toucher plus de monde ? Est-ce que "l'erreur" n'a pas été bénéfique ? Si oui, peut on encore parler "d'erreur" ?
[^] # Re: Pas trop tôt
Posté par Olivier . Évalué à 5. Dernière modification le 09 septembre 2019 à 18:00.
Mon sentiment (mais ce n’est que mon sentiment) c’est que ce succès serait arrivé plus tôt s’il n’y avait pas eu ce problème de migration Python 2 / Python 3, et que ce schisme a refroidi pas mal de monde. Il a fallu attendre que Python 3 prenne de l’ampleur pour que Python décolle vraiment et dépasse le succès d’estime qu’il connaissait déjà.
Mais bon, corrélation n’est pas causalité, je suis peut-être à côté de la plaque. Il y a certainement d’autres facteurs à prendre en compte : j’ai lu que Python a beaucoup marqué de points dernièrement en sciences et dans l’IA. Python 3 y est-il pour quelque chose ou est-ce qu’il y aurait eu le même engouement si on était resté à Python 2 ? Je ne sais pas.
[^] # Re: Pas trop tôt
Posté par kif . Évalué à 1. Dernière modification le 09 septembre 2019 à 22:10.
Je pense surtout que c'est le modèle de distribution des softs qui a fait la différence.
Il y a anaconda d'un coté, mais aussi et surtout PyPI, wheel, pip et compagnie.
[^] # Re: Pas trop tôt
Posté par lolop (site web personnel) . Évalué à 3.
Quand tu utilises Anaconda (ou Miniconda), l'utilisation de pip est possible pour tout ce qui n'est pas pré-packagé. Et l'outil conda ne se limite pas à Python — c'est pour ça qu'il permet d'installer facilement un serveur Jupyter.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Pas trop tôt
Posté par yabb85 . Évalué à 3.
A l'inverse moi je vois dans mon entourage que ça lui a donné une vraie crédibilité en industrie. Ou il y a eu une vraie période de migration.
[^] # Re: Pas trop tôt
Posté par Anonyme . Évalué à 2. Dernière modification le 10 septembre 2019 à 15:51.
La migration Python 2 → 3 me fait penser à la migration de IPvVieux à IPv6 (et les trous du cul qui refusent la migration également).
Tu retrouves d’ailleurs les mêmes choses des 2 côtés, par exemple :
La différence c’est qu’avec Python 2 on peut imposer une date de fin, ce n’est malheureusement pas le cas pour IPv4.
[^] # Re: Pas trop tôt
Posté par vpo . Évalué à 5. Dernière modification le 10 septembre 2019 à 23:34.
Un rapide coup d’œil sur le Github de Calibre m'indique qu'il y a des commits avec du "py3 fix" dans la description et des pull requests sur le sujet. Donc il a dû finir par se faire une raison…
# Traduction de la documentation officielle
Posté par Frubversion . Évalué à 2.
Pour les modérateurs : l'article de la documentation officielle mentionné dans Migration vers Python 3 vient d'être traduit en français.
[^] # Re: Traduction de la documentation officielle
Posté par Frubversion . Évalué à 1.
Correction : le lien ci-dessus pointe vers la documentation de la version en développement (3.9). La traduction a été faite pour la documentation de la version 3.7 et a été portée vers la documentation de la 3.8.
# Grumpy
Posté par Martius . Évalué à 3.
Hello, la section sur la migration à Go est incorrecte.
Grumpy est un transpileur Python 2 vers Go expérimental dont l'objectif était de voir si il était possible de mieux gérer la concurrence sur les frontaux de Youtube.
(cf: https://opensource.google.com/projects/grumpy)
Ça ne permet pas de migrer une base de code Python vers Go.
À ma connaissance, personne ne travaille sur ce projet chez Google/Youtube, et il n'y a aucune décision allant dans le sens d'une migration du code écrit en Python vers Go.
[^] # Re: Grumpy
Posté par Oliver (site web personnel) . Évalué à 3.
Merci pour ta précision. 👍
J’ai aussi eu une information similaire de la part d’un développeur qui travaille chez Google YouTube : pour la perf, des outils en C++, des scripts sont restés en Python (avec migration vers Python3), et aussi des logiciels porté vers Go. À prendre avec des pincettes, n’ayant pas pu vérifier…
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Grumpy continue !
Posté par Oliver (site web personnel) . Évalué à 2. Dernière modification le 13 novembre 2019 à 00:55.
Bien que Google n’investît plus dans le projet Grumpy, le projet a été bifurqué (fork) et il est activement maintenu, toujours dans l’idée de convertir le bon vieux code source Python 2 vers Go :
Autres projets pour aider à porter Python vers d’autres langages :
Projet connexe :
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.