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 Cilyan Olowen . En réponse à la dépêche Python — partie 2 ―Python 2. É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
sixen 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. :)