Python — partie 2 ―Python 2

Posté par Oliver (site web personnel) le 08 septembre 2019 à 21:51. Édité par Ysabeau 🧶 🧦, Davy Defaud, Benoît Sibaud et palm123. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

sept.

2019

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 1^er 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 (32 clics)
Python — partie 4 — Py Pyenv (8 clics)
Python — partie 5 — Nix (et Guix) (5 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 (9 clics)
Python — partie 10 — Entretiens (3 clics)

# Propagande /usr/bin/env ?

Posté par haleth le 08 septembre 2019 à 22:23. É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 le 08 septembre 2019 à 22:46. É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 pour env. 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 le 08 septembre 2019 à 23:42. Évalué à 4.
    
    Merci pour cette réponse étrangement complémentaire à l'article
  - [^] # Re: Propagande /usr/bin/env ?
    
    Posté par harlock974 le 09 septembre 2019 à 08:50. É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 🦦 le 09 septembre 2019 à 08:53. É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 pour bash, 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 le 09 septembre 2019 à 09:24. Évalué à 9. Dernière modification le 09 septembre 2019 à 09:24.
      
      Je n'ai pas très bien compris pourquoi #!/usr/bin/env python3 est mieux que #!/usr/bin/python3.
      
      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 (site web personnel) le 09 septembre 2019 à 15:52. Évalué à 5. Dernière modification le 09 septembre 2019 à 15:55.
      
      Mais, à part l'exemple très particulier d'Android, env est-il toujours sous /usr/bin/ ?
      
      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, dont env fait partie.
      
      Edit : ce que j'avais écrit initialement ne voulait au final rien dire.
      - [^] # Re: Propagande /usr/bin/env ?
        
        Posté par Vincent Danjean le 10 septembre 2019 à 09:49. É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 le 10 septembre 2019 à 12:55. É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 le 10 septembre 2019 à 13:37. É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 un grep /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.
        
        gens vindicatifs imposer leur pratiques
        
        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 le 10 septembre 2019 à 14:25. Évalué à 3.
        
        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/.
        
        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 dire grep "/usr/bin/env python" *)
        
        [^] # Re: Propagande /usr/bin/env ?
        
        Posté par barmic 🦦 le 10 septembre 2019 à 14:28. Évalué à 0.
        
        justement et que /usr/bin/python2 et /usr/bin/python3 ne sont même pas mentionnés.
        
        /usr/bin/python2 ne devrait pas exister. python c'est python 2 et ce ne sera jamais python 3.
        
        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/.
        
        Il reste qu'à savoir si env doit être dans dans le premier dossier des exécutables.
        
        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.
        
        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 le 10 septembre 2019 à 17:01. Évalué à 5.
        
        justement et que /usr/bin/python2 et /usr/bin/python3 ne sont même pas mentionnés.
        
        /usr/bin/python2 ne devrait pas exister. python c'est python 2 et ce ne sera jamais python 3.
        
        Mmm, la PEP 0394 n'est pas si franche à ce sujet.
        
        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
        
        Oui, je parlai de ça :-)
        
        [^] # Re: Propagande /usr/bin/env ?
        
        Posté par calandoa le 10 septembre 2019 à 14:43. É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 le 10 septembre 2019 à 17:17. Évalué à 4. Dernière modification le 10 septembre 2019 à 17:19.
        
        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.
        
        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.
        
        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…
        
        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 de env 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 le 12 septembre 2019 à 11:37. Évalué à 3.
        
        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.
        
        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 le 10 septembre 2019 à 15:55. Évalué à 1.
        
        il semble que pour les BSD passer par env soit plus fonctionnel
        
        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 le 10 septembre 2019 à 13:45. É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) le 18 septembre 2019 à 11:44. É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) le 08 septembre 2019 à 23:06. É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 le 09 septembre 2019 à 01:26. Évalué à 10.

Et toi, comment vis tu cette fin de Python 2 ?

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.

Tes conseils pour gérer la transition ?

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.

sniff, on avait enfin une version stable de Python ? 💚 💚

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) le 09 septembre 2019 à 11:30. Évalué à 7.
  
  Surtout que la migration n’était quand même pas bien compliquée.
  
  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 les bytes par exemples, il me semble que ça a fortement aidé à la migration de Twisted), et des dépendances qui pouvaient manquer.
  
  Aucun. Fallait migrer il y a longtemps. Genre il y a dix ans. T’aurais eu moins de boulot. ;)
  
  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 le 09 septembre 2019 à 12:51. É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) le 09 septembre 2019 à 15:03. É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) le 09 septembre 2019 à 17:10. É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) le 09 septembre 2019 à 16:16. Évalué à 7.
  
  Les changements progressifs encouragent les dévs à ne pas se crisper sur une version.
  
  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 le 09 septembre 2019 à 17:00. Évalué à 3. Dernière modification le 09 septembre 2019 à 17:01.
    
    Je vais reformuler ma pensée imprécise. J’ai dit:
    
    Les changements progressifs encouragent les dévs à ne pas se crisper sur une version.
    
    J’aurais dû dire pour être plus précis:
    
    Les changements progressifs encouragent les dévs à ne pas tous se crisper en même temps sur une même version.
    
    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 le 09 septembre 2019 à 17:29. Évalué à 4.
      
      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).
      
      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 le 09 septembre 2019 à 18:00. É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 le 09 septembre 2019 à 22:10. É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) le 09 septembre 2019 à 23:12. É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.
        
        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
        
        [^] # Re: Pas trop tôt
        
        Posté par yabb85 le 09 septembre 2019 à 23:15. É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 le 10 septembre 2019 à 15:47. É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 :
  - Python : Calibre qui refuse de migrer à Python 3 (le dev est persuadé de pouvoir maintenir Python 2 tout seul) ou des logiciels écrits récemment mais en Python 2 (je pense à toi saloperie de SaltStack (2011)) ;
  - IP : Kubernetes (2014-2015) qui commence à peine à supporter le dual stack depuis quelque jours/semaines.
  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 le 10 septembre 2019 à 23:33. É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 le 11 septembre 2019 à 18:23. É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 le 11 septembre 2019 à 23:19. É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 le 16 septembre 2019 à 15:57. É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) le 18 septembre 2019 à 11:54. É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) le 13 novembre 2019 à 00:53. É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 :
  - https://github.com/grumpyhome
  Autres projets pour aider à porter Python vers d’autres langages :
  - Python vers C++ https://github.com/serge-sans-paille/pythran
  - Python vers Rust (incomplet) https://github.com/konchunas/pyrs
  - Python 2.4..2.6 vers C++ (expérimental) https://github.com/DevJohan/shedskin
  - Python 3.6.5 vers Rust (incomplet) https://github.com/joncatanio/cannoli
  - Python 2 et 3 vers C++ (abandonné) https://github.com/ProgVal/py14/tree/python-3
  - Python vers JavaScript 6 https://pypi.org/project/Transcrypt/#description
  - Python vers C++ (alpha) https://github.com/pradyun/Py2C
  - Python vers C++ (abandonné) https://github.com/pybee/seasnake
  - Python vers C++ (inactif) https://github.com/andreikop/cpp2python
  - Pseudo-Python vers Python/Ruby/JS/Go/C#/C++/Swift https://github.com/pseudo-lang/pseudo-python
  Projet connexe :
  - Haxe vers Python3.2/JS/C++98/C#/Java/Lua/PHP7/… https://github.com/HaxeFoundation/haxe
  Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)