IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Python Discussion :

Python Software Foundation annonce qu’elle mettra fin au support de Python 2 à partir du 1er janvier 2020


Sujet :

Python

  1. #41
    Expert éminent
    Avatar de fred1599
    Homme Profil pro
    Lead Dev Python
    Inscrit en
    Juillet 2006
    Messages
    3 784
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : Lead Dev Python
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 784
    Points : 7 043
    Points
    7 043
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Python, c'est bien pour prototyper ou si les algos se résument à des appels à numpy/scipy (dont une grosse partie du code est en C/C++/Fortran). Mais quand les algos deviennent plus complexes, la lenteur de python est souvent rédhibitoire. Et ça ne risque pas de changer, à cause de ses choix de conception (typage dynamique, pas de compilation JIT efficace, GIL...). Au boulot, on utilise de plus en plus Julia et ça nous change la vie.
    Ce temps là est bien révolu, il faut se mettre à la page... Qui puis est travailler avec python simplifie et fait gagner beaucoup de temps sur le codage, mais en plus il s'interface avec des langages tels que le C/C++/Fortran. Je ne vois pas pourquoi s'en passer, même pour des algorithmes demandant beaucoup de performance.

    Je connais Julia, c'est un super langage, il reste néanmoins qu'il a encore un certains manque de maturité, qui se comblera très vite je pense. Il y en a d'autres qui percent comme crystal, si tu as l'occasion de le tester et de l'utiliser au taf, vas-y !

    P.S : Il n'y a pas que numpy/scipy dans la vie, si on cherche plus loin, voir cython, numba, panda, PyCuda, ... bref, c'est l'avantage de ce langage, le nombre de glues dans tous les domaines.
    Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
    La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)

  2. #42
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par fred1599 Voir le message
    Ce temps là est bien révolu, il faut se mettre à la page...
    Merci, ça fait toujours plaisir de se faire traiter d'arriéré. Donc Python est devenu performant, fait du typage statique optimisé et n'a plus de GIL ? J'ai dû faire un coma de plusieurs années...

    Citation Envoyé par fred1599 Voir le message
    Qui puis est travailler avec python simplifie et fait gagner beaucoup de temps sur le codage, mais en plus il s'interface avec des langages tels que le C/C++/Fortran.
    Oui, c'est un peu ce j'ai dit en fait.

    Citation Envoyé par fred1599 Voir le message
    Je ne vois pas pourquoi s'en passer, même pour des algorithmes demandant beaucoup de performance.
    Parce qu'en HPC, on cherche à maximiser les performances. Numpy/scipy et plein d'autres bibliothèques ont la moitié de leur code en C/C++/Fortran. Si Python était si performant, elles seraient 100% codées en python.

    Citation Envoyé par fred1599 Voir le message
    Je connais Julia, c'est un super langage, il reste néanmoins qu'il a encore un certains manque de maturité, qui se comblera très vite je pense.
    Ah bah mince alors, je vis dans le passé mais dans un passé immature.

    Citation Envoyé par fred1599 Voir le message
    Il y en a d'autres qui percent comme crystal, si tu as l'occasion de le tester et de l'utiliser au taf, vas-y !
    Ah oui, Crystal... il perce tellement qu'il faut presque toujours expliquer ce que c'est et indiquer sa page web... Crystal n'a pas les mêmes objectifs que Julia et n'est pas adapté au HPC actuellement.

  3. #43
    Expert éminent
    Avatar de fred1599
    Homme Profil pro
    Lead Dev Python
    Inscrit en
    Juillet 2006
    Messages
    3 784
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : Lead Dev Python
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 784
    Points : 7 043
    Points
    7 043
    Par défaut
    Merci, ça fait toujours plaisir de se faire traiter d'arriéré. Donc Python est devenu performant, fait du typage statique optimisé et n'a plus de GIL ? J'ai dû faire un coma de plusieurs années...
    Je suis pas tout jeune, ça fait énormément de temps qu'on dit que python sert pour du prototypage. Effectivement il peut être utilisé pour ça... mais pas que pour ça ! Ah et j'oubliais, oui python fait du typage statique.

    Parce qu'en HPC, on cherche à maximiser les performances. Numpy/scipy et plein d'autres bibliothèques ont la moitié de leur code en C/C++/Fortran. Si Python était si performant, elles seraient 100% codées en python.
    Ouais pour ce cas très spécifique, on jette python dans la case prototypage ?

    À savoir qu'on peut faire plus rapide que numpy/scipy avec cython par exemple, mais numba ça doit être possible aussi.

    Ah oui, Crystal... il perce tellement qu'il faut presque toujours expliquer ce que c'est et indiquer sa page web... Crystal n'a pas les mêmes objectifs que Julia et n'est pas adapté au HPC actuellement.
    Mais... parlait-on d'HPC dans notre discussion préalablement ? C'est ultra spécifique comme domaine, et il ne me semble pas qu'on parlait de python et HPC, mais bien de la limite que tu apportais à python, le prototypage de code.
    Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
    La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)

  4. #44
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par fred1599 Voir le message
    oui python fait du typage statique.
    Bien vu. Mais c'est encore loin d'être répandu et efficace : "The typing module has been included in the standard library on a provisional basis".

    Citation Envoyé par fred1599 Voir le message
    À savoir qu'on peut faire plus rapide que numpy/scipy avec cython par exemple, mais numba ça doit être possible aussi.
    Réécrire les sections de code critiques en Cython (ou en C/C++/Fortran) demande un vrai travail. C'est d'ailleurs un des avantages de Julia que d'éviter ça.

    Citation Envoyé par fred1599 Voir le message
    Mais... parlait-on d'HPC dans notre discussion préalablement ? C'est ultra spécifique comme domaine, et il ne me semble pas qu'on parlait de python et HPC, mais bien de la limite que tu apportais à python, le prototypage de code.
    Justement, je parlais du HPC spécifiquement, en réponse à un message précédent. Si tu avais lu correctement mon message avant d'y répondre, tu le saurais.

  5. #45
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Parce qu'en HPC, on cherche à maximiser les performances. Numpy/scipy et plein d'autres bibliothèques ont la moitié de leur code en C/C++/Fortran. Si Python était si performant, elles seraient 100% codées en python.
    Oui et alors ?
    On s'en fou de comment est codé Numpy, Opencl, ou cuda... ce qui compte c'est de les utiliser efficacement !

    Le C/C++ n'est pas plus performant que python avec numpy... pour la simple et bonne raison que numpy est une lib optimisé.
    Faire du from scratch en C/C++ serait contre productif pour un gain de perf (si tu en as un) ridicule.

    Faire un code performant c'est tres difficle meme pour un expert en C, il est plus simple de partir sur des trucs tous fait, avec python je peut faire mes matrices avec numpy et faire des calcules sur gpu avec cuda/opencl sans passer 3ans pour le faire.
    Avec Python je peut tous faire dans 1 seul programme et dans 1 seul "langage" (pycuda/pyopencl j'en conviens c'est pas du python mais il s’intègre très bien dans le code)
    Une fois mes calcules fait je peut les afficher directement avec Vispy, ou si je veut faire de la 3D plus poussé j'utilise Panda3D voir je peut y intégrer du code opengl/vulkan pour les parties les plus critiques

    Tous ceci dans 1 seul fichier .py

    edit: pour le probleme des dépendances moi j’utilise anaconda portable, un simple copier-coller et hop mon code marche peu importe le cluster.

    Je parle de numpy/scipy parceque ces lib ont une très bonne réputation dans le milieu, aucun autre langage n'a de lib comparable (scipy avec des centaines de formules toute faite comme la sigmoïde, la transformation de fourrier...etc)
    J'ai pas essayer crystal (connait pas) par contre j'ai déjà fait des prototypes en Go et en julia mais j'ai pas été convaincue, je vois pas ce qu'ils offre de plus que python.
    Pour python, il faut aussi savoir que Intel me donne une version optimisé pour ces cpu ce qui apporte un gros gain non négligeable.

  6. #46
    Expert éminent
    Avatar de fred1599
    Homme Profil pro
    Lead Dev Python
    Inscrit en
    Juillet 2006
    Messages
    3 784
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : Lead Dev Python
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 784
    Points : 7 043
    Points
    7 043
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Justement, je parlais du HPC spécifiquement, en réponse à un message précédent. Si tu avais lu correctement mon message avant d'y répondre, tu le saurais.
    Pas de mauvaise foi, là où je suis intervenu, c'est sur ta réflexion concernant les limites que tu apportes à ce langage, que je considère comme fausse... On ne peut pas dire que ce langage s'arrête à du prototypage de code.

    Pour le HPC ne connaissant pas trop le domaine, je me suis pas permis d'exprimer sur ce sujet et je ne le veux pas.
    Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
    La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)

  7. #47
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par fred1599 Voir le message
    Pas de mauvaise foi, là où je suis intervenu, c'est sur ta réflexion concernant les limites que tu apportes à ce langage, que je considère comme fausse... On ne peut pas dire que ce langage s'arrête à du prototypage de code.
    Bon d'accord, tu as raison : je suis un arriéré de mauvaise foi qui ne sait pas lire et qui dit n'importe quoi.
    Allez salut.

  8. #48
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    Janvier 2014
    Messages
    1 089
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 089
    Points : 26 554
    Points
    26 554
    Par défaut Python Software Foundation annonce qu’elle mettra fin au support de Python 2 à partir du 1er janvier 2020
    Python Software Foundation annonce qu’elle mettra fin au support de Python 2 à partir du 1er janvier 2020
    et prévient qu’elle n’apportera plus son aide pour tout problème lié à Python 2 après cette date

    Depuis la sortie de Python 3.0, il est fortement recommandé d’abandonner les versions antérieures du langage de programmation Python au profit de cette dernière version. En mars dernier, Guido van Rossum, le créateur et leader du projet du langage de programmation Python, a annoncé que le support de la version 2.7 de python prendra fin le 1er janvier 2020. Après cette échéance, Python 2.7 ne bénéficiera plus d’aucune mise à jour, pas même pour des correctifs de sécurité. Bien évidemment, il est toujours possible que des développeurs indépendants fassent un fork de Python 2.7 pour assurer sa continuité. Mais pour Guido van Rossum, il ne faudra plus attendre de sa part et de son équipe des mises à jour ou même des décisions afférentes au développement de Python 2.7. Ce fait n’est pas sans importance, car dans la communauté Python, Guido van Rossum est considéré comme le dictateur bienveillant à vie.

    Après l'annonce de Guido van Rossum, il était certain qu'une annonce plus officielle serait faite dans le même sens. Depuis quelques heures, la Python Software Foundation (PSF) a annoncé que le « 1er janvier 2020 serait le jour où elle mettra fin à Python 2. Cela signifie que nous ne l’améliorerons plus après ce jour-là, même si quelqu’un y trouve un problème de sécurité. Vous devriez passer à Python 3 dès que possible », suggère la fondation. Nous rappelons que la Python Software Foundation qui est composée de bénévoles a pour objectif de promouvoir, protéger et faire progresser le langage de programmation Python, ainsi que de soutenir et de faciliter la croissance de la communauté internationale des développeurs Python.

    Selon la fondation, cette décision a été prise pour aider les utilisateurs de Python. Pour mieux se faire comprendre, la fondation donne les explications suivantes :

    « Nous avons publié Python 2.0 en 2000. Quelques années plus tard, nous avons réalisé que nous devions apporter de grands changements pour améliorer Python. Donc, en 2006, nous avons lancé Python 3.0. Beaucoup de personnes n’ont pas effectué de mise à niveau et nous ne voulions pas leur faire de mal. Ainsi, depuis de nombreuses années, nous avons continué à améliorer et à publier Python 2 et Python 3 ».

    « Mais cela rend difficile l’amélioration de Python. Il y a des améliorations que Python 2 ne peut pas gérer. Et nous avons moins de temps pour améliorer et accélérer Python 3. Et si de nombreuses personnes continuent à utiliser Python 2, les volontaires qui utilisent Python pour la création de logiciels en pâtissent. Ils ne peuvent pas utiliser les nouvelles fonctionnalités de Python 3 pour améliorer les outils qu’ils développent ».

    « Nous ne voulions pas faire de mal aux utilisateurs de Python 2. Nous avons donc annoncé en 2008 que nous arrêterions Python 2 en 2015 et demandé aux personnes de passer à la version suivante avant cette date. Certains l’ont fait, d’autres pas. Donc, en 2014, nous avons prolongé cette échéance jusqu’en 2020 ». Mais à compter du 1er janvier 2020, la PSF annonce qu'elle mettra fin au support de Python 2.

    Nom : Python 2 RIP.jpg
Affichages : 30151
Taille : 43,4 Ko

    Pour les personnes qui s’entêteront et continueront à utiliser Python 2 après cette date, la fondation souligne que si elles « rencontrent des problèmes de sécurité catastrophiques dans Python 2 ou des logiciels écrits en Python 2 », les volontaires [de PSF] ne les aideront pas. « Certains de ces problèmes commenceront le 1er janvier. D’autres problèmes s’aggraveront avec le temps », prévient PSF. En continuant à utiliser Python 3, « vous perdrez vos chances d’utiliser de bons outils, car ils ne fonctionneront que sur Python 3, et vous ralentirez les personnes qui dépendent de vous et travaillent avec vous ». Pour les logiciels écrits en Python 2, la PSF recommande de se tourner vers les outils de portage du code Python 2 vers Python 3. Certains développeurs qui sont passés de Python 2 à Python 3 affirment que cela a été la transition la plus facile jamais faite. Il existe une bibliothèque pour aider les développeurs à migrer leur code vers Python 3 et dans presque tous les cas, il est possible d’écrire du code compatible Python 2 et 3, fait remarquer un développeur.

    Si par contre vous avez acheté un logiciel tiers déjà écrit en Python 2, il est conseillé de demander au fournisseur s’il dispose d’une assistance pour ce logiciel. Si ce n’est pas le cas, La PSF recommande quelques fournisseurs qui proposent contre rémunération une assistance technique pour Python 2. Nous avons Abilian, ActiveState, Python Academy et Snakedev.

    Source : Python Software Foundation

    Et vous ?

    Quels commentaires faites-vous de la décision de la Python Software Foundation ?

    Selon vous, devrait-on continuer à maintenir Python 2 ? Pour quelles raisons ?

    Voir aussi

    Meilleurs langages en 2019 selon l’IEEE : Python leader pour la troisième année consécutive, il s’impose dans tous les domaines dans lesquels il est utilisé, du développement web à l’embarqué
    Meilleurs langages en 2018 selon l’IEEE : Python conforte sa place de leader grâce à son ascension dans le machine learning et l’embarqué
    Netflix : Python est derrière chaque film que vous regardez, voici comment l’entreprise utilise le langage de programmation pour ses services
    Python 3.8.0 : la première version bêta est publiée avec une API C pour améliorer la configuration de l’initialisation
    Éducation : Python bientôt langage officiel de programmation en France ? Un projet dans le cadre de la réforme du Bac et du lycée
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  9. #49
    Membre confirmé
    Profil pro
    DIRLO
    Inscrit en
    Juillet 2009
    Messages
    197
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : DIRLO

    Informations forums :
    Inscription : Juillet 2009
    Messages : 197
    Points : 517
    Points
    517
    Par défaut
    Citation Envoyé par Olivier Famien Voir le message
    « Nous avons publié Python 2.0 en 2000....

    la PSF a vraiment dit ça ... waou!

  10. #50
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Bravo à Python pour avoir montré l'exemple de ce qu'il ne faut pas faire pour assurer une transition réussie. Et non ce n'est même pas ironique. La mésaventure de Python aura au moins servi d'exemple aux langages modernes qui se sont globalement bien mieux tiré du guêpier qu'est un changement incompatible, même si ça restera toujours quelque chose de compliqué.

    Avec la fin du support de Python 2 on peut espérer que l'un des problèmes les plus récurrent de python disparaitra enfin.

  11. #51
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2009
    Messages
    2 004
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2009
    Messages : 2 004
    Points : 5 423
    Points
    5 423
    Par défaut
    Citation Envoyé par Uther Voir le message
    La mésaventure de Python aura au moins servi d'exemple au langages modernes qui se sont bien mieux tiré (même si ça n'est toujours pas évident) du guêpier qu'est un changement incompatible.
    Va dire ca aux utilisateurs d'Angular . Bon c'est un framework mais bon ca reste bien embêtant pour les pioneers qui ont participé à sa popularisation et qui se sont bien fait remercier!

  12. #52
    Membre confirmé Avatar de Andarus
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2008
    Messages
    137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2008
    Messages : 137
    Points : 455
    Points
    455
    Par défaut
    Citation Envoyé par Uther Voir le message
    La mésaventure de Python aura au moins servi d'exemple au langages modernes qui se sont bien mieux tiré (même si ça n'est toujours pas évident) du guêpier qu'est un changement incompatible.
    Tu pourrais citer des exemples ça m’intéresse?

  13. #53
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Un exemple que je j'ai bien suivi est le langage Rust : il a mis en place un changement de syntaxe en 2018. Python et Perl ont clairement fait figure d'exemple à ne pas suivre lors des discutions sur la stratégie à adopter.
    Leur solution finale a consisté à laisser chaque crate (l'équivalent du paquet) choisir l'édition qu'elle utilise(2015 ou 2018). Le compilateur est capable de compiler les deux éditions et les crates de différentes éditions peuvent interagir de manière totalement transparente.
    Si l'édition n'est pas spécifiée c'est l'édition 2015 qui est employée, ainsi les anciennes crates continuent de fonctionner de manière totalement transparente, cependant l'outil qui crée les nouvelles crates définit par défaut la version à 2018.

    J'ai moins suivi leur cas, mais il me semble que Go et Swift ont mis en place eux aussi des changements majeurs sans diviser lourdement leurs utilisateurs.

  14. #54
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    Par défaut
    ils auraient du abandonner python 2 dès que python 3 était suffisamment stable, dans les environ de 2010 si mes souvenirs sont bons.
    là ils ont juste donné des excuses aux utilisateurs de python 2 pour ne pas migrer rendant au fur et à mesure la migration de plus en plus difficile.
    de toute façon si les utilisateurs ne veulent pas migrer, ils feront tout pour ne pas le faire, autant dans ce cas ne pas s'emmerder avec ces personnes là, ils sont une perte de temps, autant se consacrer sur l'avenir et les gens qui le supporte.

  15. #55
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 235
    Points : 36 684
    Points
    36 684
    Par défaut
    Citation Envoyé par stardeath Voir le message
    de toute façon si les utilisateurs ne veulent pas migrer, ils feront tout pour ne pas le faire, autant dans ce cas ne pas s'emmerder avec ces personnes là, ils sont une perte de temps, autant se consacrer sur l'avenir et les gens qui le supporte.
    Une stratégie de migration va dépendre du nombre d'utilisateurs impactés, de la quantité de bibliothèques à migrer pour qu'ils puissent migrer leurs propres applications et du coût, pour les différents développeurs, de maintenir une version python2 et une version "python3".

    Et si la communauté Python était restée droit dans ses bottes, on aurait peut être eu droit à un fork pour tous ceux qui se sentaient un peu abandonnés.

    A la place, nous avons eu des outils comme six qui permettent de maintenir des versions python2 et python3 assez facilement... Et plus de délais pour que cette migration ne soit pas une punition mais l'occasion d'apporter de nouvelles fonctionnalités aux utilisateurs finaux tout en profitant (un peu) de celles du langage.

    Le choix étant comme toujours entre avancer plus vite et se retrouver un peu seul ou ralentir pour permettre aux autres de suivre.

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  16. #56
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    Par défaut
    selon mon expérience perso, dans les boites dans lesquelles je suis passé, la hiérarchie ne daigne pas regarder pour mettre les technos à jour tant qu'on leur met pas un couteau sous la gorge. donc plus de délais, pour moi ça signifie pas de migration et l'accumulation de code en python 2 qui augmentera la charge de travail lors de la vraie migration en python 3 car on aura plus le choix. (et j'ai testé les outils pour gérer python 2 et 3 en même temps, j'ai eu très vite envie de me pendre tellement ça rajoutait de contraintes)

    pareil, dans les différentes boites où je suis passé, on est plus dans la stratégie de faire des commits unitaires, avec des fonctionnalités bien séparées et pas faire un commit fourre tout, pour être capable d'identifier plus facilement les problèmes entre les différentes versions, etc. (je vais pas faire la panoplie des avantages de pas modifier la terre entière à chaque commit), mais par contre dans ces mêmes boites, on n'applique pas la même stratégie pour la mise à jour des composants tiers ; là on attend le plus possible en faisant des bidouilles pas possible pour contourner les manques/bugs de ces composants, et dès que tu as le feu vert pour mettre à jour, il faudrait que ça soit immédiat et sans régression.

    toujours pour moi, il faut arrêter ce double standard, soit on reste figé à un instant T, et on assume ; soit on se met à jour de façon régulière pour limiter les conséquences de delta trop important.

  17. #57
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 235
    Points : 36 684
    Points
    36 684
    Par défaut
    Salut,

    Citation Envoyé par stardeath Voir le message
    selon mon expérience perso, dans les boites dans lesquelles je suis passé, la hiérarchie ne daigne pas regarder pour mettre les technos à jour tant qu'on leur met pas un couteau sous la gorge.
    C'est une attitude humaine normale! Si on vous dit, il faut réaliser çà dans X mois, vous estimez la quantité de boulot à faire... Puis vous essayez de le facturer au client (car il faut bien vous payer à la fin du mois) et si la seule raison pour effectuer le boulot est juste d'être de conformité avec mais que çà n'apporte rien de plus aux utilisateurs (de l'application), c'est pas gagné.

    Citation Envoyé par stardeath Voir le message
    pour moi ça signifie pas de migration et l'accumulation de code en python 2 qui augmentera la charge de travail lors de la vraie migration en python 3 car on aura plus le choix
    Le client sait qu'il devra migrer au plus tard à la date X et combien çà risque de lui coûter en prestations et en interne (parce qu'il va certainement falloir immobiliser des employés pour tester un peu plus lourdement la chose).
    Si l'application doit subir des évolutions majeures (et que toutes les bibliothèques externes sont disponibles), il peut en profiter pour "migrer": il optimise le coût des tests.

    S'il n'y a que des opérations de maintenance, il va attendre... Et cela ne coûtera pas forcément plus cher car le coût d'une migration n'est pas une fonction du nombre de lignes de code ou des fonctionnalités (c'est plus compliqué) et il profitera de l'expérience acquise par les autres sur Python3 (en trouvant plus facilement des solutions en cherchant sur Internet).

    Maintenant, si je suis une SSII et que j'ai 50 clients pour cette application, je sais que je peux essayer d'investir pour migrer car j'ai on espoir qu'in fine, X % de ces clients migreront (un jour)... et charger le coût sur X * 50.

    Ce n'est pas le même scénario et chaque application a sa propre trajectoire en fonction de tas de considérations externes (la deadline - quand migrer au plus tard - en étant une parmi d'autres).

    Citation Envoyé par stardeath Voir le message
    On n'applique pas la même stratégie pour la mise à jour des composants tiers ; là on attend le plus possible en faisant des bidouilles pas possible pour contourner les manques/bugs de ces composants, et dès que tu as le feu vert pour mettre à jour, il faudrait que ça soit immédiat et sans régression.
    Ben oui, mais il suffit de regarder les contraintes économiques et les implications de changements de version qui posent toujours problème car il faut "tester" et on sait rarement si on a bien testé avant de balancer le truc en production. Donc... on tempère car on n'a pas envie de se faire fusiller par le directeur de la production ou le directeur des ventes qui va expliquer combien coûte un arrêt d'une heure, d'une journée,... sans compter les impacts sur l'image quand on ne peut pas consulter la base de donnée pour avoir l'état d'une livraison, d'une commande,...

    C'est comme çà... bienvenue dans le monde de l'informatique d'entreprise.

    Mais le gros soucis dans la migration Python3 a été la disponibilité des bibliothèques tierces. Car là, même si le client veut migrer, on ne peut pas (sauf à changer de bibliothèque mais les coûts sont autres).

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  18. #58
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    Janvier 2014
    Messages
    1 089
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 089
    Points : 26 554
    Points
    26 554
    Par défaut Alors que la fin du support de Python 2.7 approche à grands pas, certains utilisateurs se réjouissent
    Alors que la fin du support de Python 2.7 approche à grands pas, certains utilisateurs manifestent leur réjouissance
    tandis que d’autres affichent de la tristesse, comment accueilliez-vous la fin de Python 2.7 ?

    En septembre dernier Python Software Foundation (abrégé PSF) qui a pour objectif de promouvoir, protéger et faire progresser le langage de programmation Python, ainsi que de soutenir et de faciliter la croissance de la communauté internationale des développeurs Python a annoncé que le « 1er janvier 2020 serait le jour où elle mettra fin à Python 2 ». Pour la fondation, cela signifie qu’aucune amélioration ne sera apportée au langage après ce jour-là, même si quelqu’un y trouvait un problème de sécurité. « Vous devriez passer à Python 3 dès que possible », a martelé PSF.

    Il faut souligner que depuis 2015, il était prévu de mettre fin au support de Python 2.7. Mais face à la grande utilisation de cette version, cette première échéance a été reportée au 1er janvier 2020 afin de donner du temps supplémentaire aux individus et entreprises pour migrer vers Python 3. Après plusieurs années d’attente, 2020 est maintenant à la porte. Plus que 2 jours pour passer à la nouvelle année. Pour certains, c’est le lieu de se souvenir de tous les bons moments que l’on a pu passer avec cette version du langage. Aussi pour marquer la fin de Python 2, un utilisateur a eu l’idée de mettre en ligne un compte à rebours affichant le temps restant pour atteindre l’échéance fixée. Derrière cette démarche, l’utilisateur déclare qu’il souhaite organiser une fête pour rendre hommage à Python 2 à la conférence annuelle PyCon 2020 qui aura lieu du 15 au 25 avril 2020, aux États-Unis.

    Si pour certains la fin du support de Python 2 constitue un moment de réminiscence des bons moments passés, pour d’autres par contre, c’est avec beaucoup de chagrin qu’ils abordent cette page qui tourne. Un utilisateur répondant au pseudonyme d’AlexMax confesse qu’il « ne peut pas s’empêcher de se sentir un peu triste ».

    Nom : Python-RIP.gif
Affichages : 35527
Taille : 120,8 Ko

    Pour lui, « à un niveau fondamental, la migration de 2 à 3 n’était rien de moins qu’un désastre complet, et a complètement tué son enthousiasme pour travailler avec le langage ». Comme arguments, il avance que les changements apportés dans Python 3 sont de nature à plus donner le mal de tête à ceux qui veulent effectuer la migration qu’à les encourager. Et pour cause, il met en avant les points suivants :

    • la représentation fondamentale des chaînes de caractères a changé pour le pire et non le meilleur ;
    • la gestion des paquets était et demeure un cauchemar en utilisant une combinaison d’environnements virtuels pip pour installer les dépendances spécifiques au projet ;
    • comparé à d’autres langages, Python 3 est toujours lent, car il ne valoriserait que la simplicité par convention ;
    • la bibliothèque asyncio permettant d’écrire du code concurrent en utilisant la syntaxe async/await aurait été ajoutée assez tardivement ;
    • des indications de type ont été ajoutées au langage en s’appuyant uniquement sur des analyseurs statiques de type hinting au lieu de créer également des vérifications de type d’exécution dans le langage, ce qui aurait été beaucoup plus utile et cohérent, selon l’intervenant ;
    • jusqu’à présent, il n’y a toujours pas de fonctions lambda anonymes multilignes.


    Pour AlexMax, si l’équipe de développement de Python a reporté la première date de fin du support de Python 2.7, et s’il existe encore une forte population qui continue à utiliser Python 2.7, c’est parce qu’il n’y a pas suffisamment d’éléments motivants qui poussent à la migration vers Python 3. Au lieu de travailler à ces lacunes en implémentant de nouvelles fonctionnalités dans Python 3 pour convaincre les développeurs à migrer vers cette version, l’équipe de Python a plutôt agité le bâton en rappelant à chaque fois l’imminence de l’abandon de Python 2.x. Résultat, certains développeurs estiment qu’ils pourraient se tourner plutôt vers d’autres langages.

    Pour d’autres utilisateurs par contre, bien que reconnaissant que la transition de Python 2 vers Python 3 n’aurait pas été bien gérée, Python 2 doit mourir. Pour ces derniers, les arguments de difficulté de gestion de paquets ne sauraient être mis en avant, car la gestion des paquets serait super simple avec Python. Pour ceux qui avancent le souci de mise à niveau de leurs projets, certains utilisateurs avancent qu’ils n’ont jamais rencontré de code Python 2 qui n’a pas pu être converti en un temps raisonnablement court en utilisant 2to3, à l’exception des modules d’extension en C, qui nécessitent un certain codage manuel, principalement en raison du changement d’Unicode. Et pour ceux qui ont fait le grand saut vers Python 3, certains avancent qu’ils n’ont jamais eu à regarder en arrière, car Python 3 aurait rendu le langage beaucoup plus cohérent.

    Au-delà des réactions controversées relatives à la fin de Python 2.7, l’équipe de Python annonce que bien que le support de Python 2.7 s’arrête officiellement en janvier 2020, la version finale aura lieu après cette date. Ci-dessous le calendrier de la publication de la dernière version de Python 2.7 :

    • 2.7.18 gel du code en janvier 2020 ;
    • 2.7.18 la release candidate sera publiée en début avril 2020 ;
    • 2.7.18 mi-avril 2020.


    Après ces dates, ceux qui souhaiteront toujours utiliser Python 2.7 pourront se tourner vers une assistance tierce comme celle fournit avec RHEL qui compterait prendre en charge Python 2.7 jusqu’en 2024.

    Source : Python, Python Clock

    Et vous ?

    Utilisez-vous encore Python 2.7 ? Pourquoi ?

    Quel sentiment vous laisse la fin du support de Python 2.7 ?

    Êtes-vous enthousiaste ou plutôt triste ?

    Voir aussi

    Meilleurs langages en 2019 selon l’IEEE : Python leader pour la troisième année consécutive, il s’impose dans tous les domaines dans lesquels il est utilisé, du développement web à l’embarqué
    Meilleurs langages en 2018 selon l’IEEE : Python conforte sa place de leader grâce à son ascension dans le machine learning et l’embarqué
    Netflix : Python est derrière chaque film que vous regardez, voici comment l’entreprise utilise le langage de programmation pour ses services
    Python 3.8.0 : la première version bêta est publiée avec une API C pour améliorer la configuration de l’initialisation
    Éducation : Python bientôt langage officiel de programmation en France ; ? Un projet dans le cadre de la réforme du Bac et du lycée
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  19. #59
    Membre averti Avatar de RPGamer
    Homme Profil pro
    Ingénieur en systèmes embarqués
    Inscrit en
    Mars 2010
    Messages
    168
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur en systèmes embarqués

    Informations forums :
    Inscription : Mars 2010
    Messages : 168
    Points : 395
    Points
    395
    Par défaut
    Passage déjà fait depuis longtemps et sans grande difficulté. Sans regret, adieux Python 2.

  20. #60
    Membre averti
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Décembre 2011
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2011
    Messages : 68
    Points : 342
    Points
    342
    Par défaut
    L’existence même d'une incompatibilité aussi majeur entre deux versions est le syndrome d'un langage mal née.

    Allez, envoyez les pouces rouges.

Discussions similaires

  1. Réponses: 1
    Dernier message: 31/03/2016, 02h23
  2. ASP.Net 5 bêta 7 est disponible avec des améliorations de DNX
    Par Olivier Famien dans le forum Framework .NET
    Réponses: 0
    Dernier message: 11/09/2015, 06h36
  3. [Joomla!] Joomla 1.6 est disponible avec l'arrivée du code sémantique
    Par Idelways dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 18
    Dernier message: 18/03/2011, 11h04
  4. Réponses: 0
    Dernier message: 02/02/2010, 22h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo