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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Redacteur
    Inscrit en
    juin 2016
    Messages
    962
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

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

    Informations forums :
    Inscription : juin 2016
    Messages : 962
    Points : 26 379
    Points
    26 379
    Par défaut Athena de JPMorgan a 35 millions de lignes de code Python et ne sera pas mis à jour vers Python 3 à temps
    Athena de JPMorgan a 35 millions de lignes de code Python et ne sera pas mis à jour vers Python 3 à temps
    selon eFinancialCareers

    Depuis 2006, la Python Software Foundation (PSF) soutient deux branches du langage Python, Python 2.x et Python 3.x, mais cela prendra définitivement fin dès le 1er janvier 2020. La PSF a annoncé qu’à partir du 1er janvier 2020, elle mettra définitivement fin au support de Python 2.7 qui est la dernière mise à jour de Python 2. Mais selon eFinancialCareers, beaucoup d’entreprises comme JPMorgan ne seront pas prêtes à temps. À l'heure actuelle, la plateforme de trading Athena de JPMorgan est toujours pilotée par Python 2.7.

    La fin de vie de Python 2 a été initialement prévue pour 2015, mais elle a été finalement repoussée de cinq années par la PSF. La PSF avait ensuite demandé aux développeurs et entreprises qui utilisaient toujours Python 2 de passer à Python 3, mais jusque là, plusieurs entreprises ont encore des projets sous Python 2. Autrement dit, la PSF a estimé que ces cinq années devraient permettre aux développeurs et aux entreprises d’effectuer la migration complète de leurs différents projets vers les versions prises en charge de Python 3.x, mais cela n’a pas été le cas pour tout le monde.

    Il y a eu beaucoup d'avertissements que cela allait arriver, mais désormais la PSF ne pense plus attendre les retardataires. « Nous avons décidé que le 1er janvier 2020 serait le jour où nous arrêterons le support de 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 », a annoncé la PSF cette semaine sur son site officiel. Le compte à rebours est à nouveau lancé par la PSF, mais force est de constater que toutes les entreprises ne sont pas encore prêtes.

    À l’heure actuelle, les entreprises comme la banque JP Morgan ont toujours des projets fonctionnant sous Python 2. La plateforme de trading Athena de JPMorgan est toujours pilotée par Python 2.7. Athena est une plateforme utilisée par JPMorgan pour la tarification, la gestion des risques, l’analyse et la gestion des transactions. Selon eFinancialCareers, la feuille de route de JP Morgan montre que la banque ne pourra pas migrer complètement vers Python 3 avant la fin du support de Python 2 prévu pour le 1er janvier prochain.

    Nom : python-2-vs-python-31-780x350.jpg
Affichages : 42778
Taille : 26,9 Ko

    Contrairement à Instagram qui a terminé la migration vers Python 3 il y a environ deux ans, eFinancialCareers, un site Web de recrutement spécialisé dans les services financiers, a rapporté cette semaine que la feuille de route de JP Morgan pour migrer le code source de la plateforme Athena vers Python 3 ne lui permettra pas de respecter le délai fixé par la PSF. Selon ce que rapporte le site Web, la feuille de route prévoit que la majorité des composants stratégiques du code source d'Athena ne seront compatibles avec Python 3 qu’à la fin du premier trimestre 2020.

    Dans ce sens, ce n'est qu'à partir du quatrième trimestre de 2020 que tous les composants Python 2.7 hérités d'Athena seront compatibles avec Python 3 et que le support de JPMorgan pour Python 2 sera complètement supprimé. À en croire d’autres sources, Athena représente 35 millions de lignes de code en Python et est au cœur des négociations commerciales de JPMorgan. Selon des données présentées par Misha Tselman, directrice exécutive de JPMorgan lors d'une conférence à PyData 2017, Athena représente un ensemble complet de fonctionnalités.

    Cet ensemble complet de fonctionnalités utilise plus de 150 000 modules Python, plus de 500 packages open source et 35 millions de lignes de code Python fournies par près de 2 000 développeurs. Ceci est-il une raison valable qui justifie la lenteur dans le processus de migration vers Python 3 du code source d’Athena ? JPMorgan n'a pas apporté de commentaire sur le sujet. Toutefois, selon le site Web eFinancialCareers, elle n’est pas la seule entreprise du secteur bancaire à dépendre encore de Python 2.

    Bien que JPMorgan utilise toujours Python 2.7, ce n'est pas la seule banque dans cette position. Python 2 est largement utilisé dans le secteur financier et les banques ne sont pas toujours les plus rapides à s'adapter. Goldman Sachs utilise Python 3.6 dans son package de finances quantitatives qui est open source, mais la banque invite toujours les étudiants à passer les tests Hackerrank en Python 2. Selon certains, il semblerait que les banques sont toujours à la traîne lorsqu’il s’agit de migrer d’une technologie à une autre.

    C’est le cas d’autres langages de programmation comme le Cobol. Certaines banques ou certaines institutions financières aux États-Unis et dans le monde continuent d’utiliser des systèmes fonctionnant sous Cobol, déjà âgé de 60 ans. D'ici le milieu de l'année prochaine, les banques seront probablement l'une des dernières organisations utilisant Python 2. Avec la plupart des nouveaux développeurs qui apprennent Python 3, l'expertise de Python 2 pourrait s'avérer une compétence précieuse pendant quelques mois, jusqu'à ce que les banques passent à Python 3.

    En août dernier, plus de 100 projets Python populaires de l'écosystème Python ont annoncé dans un communiqué qu'ils comptent abandonner Python 2.x au plus tard à la fin du support officiel fixé au 1er janvier 2020. Selon leur déclaration, presque tous les packages Python open source majeurs prennent désormais en charge Python 3.x et Python 2.7, et de nombreux projets prennent en charge ces deux versions du langage depuis plusieurs années. Il existe des outils et des techniques pour maintenir la compatibilité de manière efficace, mais cela cause constamment de petits désaccords dans le développement de nombreux projets.

    « Nous souhaitons utiliser le plein potentiel de Python 3 et acceptons actuellement le coût d’écriture de code cross-compatible pour permettre une transition en douceur, mais nous n’avons pas l’intention de maintenir cette compatibilité indéfiniment », ont-ils déclaré. Ils sont environ 120 projets Python à avoir signé cette déclaration vers la fin du mois d’août passé. Parmi eux, on peut citer Tensorflow, Apache Spark, Tornado, Jupyter Notebook, Apache MXNet, Zulip, Pillow, etc. Ils ont également invité d’autres projets à se joindre à eux.

    Néanmoins, bien que la PSF compte abandonner le support de Python 2 à la date du 1er janvier 2020, des fournisseurs spécialisés proposent de prendre en charge Python 2 au-delà de la date limite de janvier et les banques et les autres entreprises en retard peuvent toujours payer pour leurs services. À cet effet, eFinancialCareers a indiqué que JPMorgan aurait déclaré l'année dernière que les 2000 développeurs travaillant sur Athena, certains d'entre eux seraient probablement dirigés vers la création de correctifs de sécurité.

    Sources : eFinancialCareers, Python Software Foundation

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi

    Plus de 100 projets Python populaires s'engagent à abandonner Python 2.x d'ici 2020. L'agence britannique de cybersécurité appelle également à arrêter de supporter cette version de Python

    Guido van Rossum envisage de mettre fin au support de Python 2.7 le 1er janvier 2020, plus de mises à jour ou correctifs de sécurité après cette date

    Python 2.7.11 est disponible avec des correctifs de bogues, mais sans nouvelles fonctionnalités
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre du Club

    Homme Profil pro
    Développeur
    Inscrit en
    janvier 2013
    Messages
    37
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : janvier 2013
    Messages : 37
    Points : 62
    Points
    62
    Billets dans le blog
    2
    Par défaut
    Sur 5 ans avec 2000 développeurs pour migrer 35 000 000 lignes de codes, cela fait environ 10 lignes par jour (par dev). Donc bon je pense que cela est acceptable, encore faut-il qu'ils aient envies d'un système sécurisé.
    (Calculs: 35.000.000/5 ~= 7.000.000 -> ~= 584.000 lignes par mois et pr 28 jours: (divisés par 2 000): 292/28 ~= 10,42)

  3. #3
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    741
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 741
    Points : 1 426
    Points
    1 426
    Par défaut
    Un tel projet a toujours des évolutions permanentes qui demande des ressources, il y a des process de test/qualif long. Cependant un développeur peut largement convertir 5 à 10 000 lignes par jour, il est clair qu'ils ont attendu le dernier moment.
    D'un tout autre point de vue, pour un projet très important et relativement stable dans le temps, un langage interprété me semble inapproprié car cela se reproduira. Java ou Go aurait été plus logique. D'autant plus que la lourdeur des tests nécessaires rend inutile la souplesse d'un langage interprété.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  4. #4
    Membre averti
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 142
    Points : 394
    Points
    394
    Par défaut
    @abriotde
    D'un tout autre point de vue, pour un projet très important et relativement stable dans le temps, un langage interprété me semble inapproprié car cela se reproduira.
    Java ou Go aurait été plus logique.
    D'autant plus que la lourdeur des tests nécessaires rend inutile la souplesse d'un langage interprété.
    En quoi un langage interprété ne serait pas approprié ?
    J’espère bien que la palanquée d'Ingénieurs/Chercheurs de JP Morgan ont fait correctement leur boulot et qu'ils ont consciencieusement choisis Python parmi la pléthore d'options dont ils disposaient.
    ils n'ont vraisemblablement pas fait ce choix au hasard.

    Et en quoi la lourdeur des tests est-elle dépendante du langage utilisé ?
    En production sur de gros projets, peut importe le langage, on auras de toute façon une "lourdeur" au niveau des test, TDD/CI/CD oblige.

    Enfin, qui te dit que le projet à été stable sur sa durée de vie ?
    D’ailleurs tu le dit toi même
    Un tel projet a toujours des évolutions permanentes qui demande des ressources ...
    Ils on forcement dut le faire grandir avec le temps, morceau par morceau, comme tout projet pharaonique le devrait. (Une pierre à la fois)

    Cependant un développeur peut largement convertir 5 à 10 000 lignes par jour, il est clair qu'ils ont attendu le dernier moment.
    Oui et Non.
    Le faite qu'ils aient attendus veut peut-être dire qu'ils ont fait autre chose à la place ...Une alternative peut-être ?
    L'affirmation qu'un développeur peut faire X watt milliers de lignes de code par jour est un pure fantasme de manager.
    Dans les faits un développeur ne pisse pas du code avec un débit régulier, il réfléchi avant (normalement) et ça ça prend du temps non calculable à l'avance.

    P.S. : 35 millions de LOC en Python aurait donner quoi en Java ou Go, je tablerais sur un petit x5 sans forcer.

  5. #5
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 937
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 937
    Points : 3 158
    Points
    3 158
    Par défaut
    Cet ensemble complet de fonctionnalités utilise plus de 150 000 modules Python, plus de 500 packages open source et 35 millions de lignes de code Python fournies par près de 2 000 développeurs.

    Rien que ces choses en gras, ça pue sévère!
    Si la réponse vous a aidé, pensez à cliquer sur +1

  6. #6
    Candidat au Club Avatar de vivid
    Profil pro
    Inscrit en
    février 2006
    Messages
    80
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 80
    Points : 3
    Points
    3
    Par défaut
    Je ne vois pas en quoi Python serait un plus... Apparemment avec ses 'modules' cela semble déjà être le bordel, en quoi l'usage du C serait plus complexe ???
    autan de ligne de code sur un si jeune langage... Mdr
    j'en fais un peu de Python.. en gros... je suis revenu en courant vers le C

  7. #7
    Membre éprouvé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    307
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 307
    Points : 1 192
    Points
    1 192
    Par défaut
    Citation Envoyé par Bill Fassinou Voir le message
    ...
    Qu'en pensez-vous ?
    ...
    L'expression qui me vient à l'esprit est "catastrophe industrielle".
    Mais je ne connais pas assez Python ni le contexte pour juger si le problème est du côté de gens un peu inexpérimentés et imprudents qui auraient choisi un langage immature et instable pour développer massivement des applications critiques, ou du côté de la gouvernance du développement de ce langage qui aurait choisi de briser une compatibilité sans grande considération pour les utilisateurs (quelles sont les différences fondamentales entre 2.7 et 3 qui ont justifié un tel saut ?).

  8. #8
    Membre averti
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 142
    Points : 394
    Points
    394
    Par défaut
    @vivid
    Je ne vois pas en quoi Python serait un plus... Apparemment avec ses 'modules' cela semble déjà être le bordel, en quoi l'usage du C serait plus complexe ???
    autan de ligne de code sur un si jeune langage... Mdr
    j'en fais un peu de Python.. en gros... je suis revenu en courant vers le C
    @wolinn
    L'expression qui me vient à l'esprit est "catastrophe industrielle".
    Mais je ne connais pas assez Python ni le contexte pour juger si le problème est du côté de gens un peu inexpérimentés et imprudents qui auraient choisi un langage immature et instable pour développer massivement des applications critiques, ou du côté de la gouvernance du développement de ce langage qui aurait choisi de briser une compatibilité sans grande considération pour les utilisateurs (quelles sont les différences fondamentales entre 2.7 et 3 qui ont justifié un tel saut ?).
    Heu juste ...Qu'est ce que vous fumez ?
    Vous dites tous les deux ne pas connaitre Python suffisamment et pourtant vous en déduisez que c'est :
    1. Un langage immature et instable.
    2. Pas adapter au projet.
    3. @vivid veut même le remplacer par du C.

    Alors :
    1. Utilisé depuis "juste" une 10e d'années sur des projets gros et complexe par "juste" tous les GAFAM (parmi d'autres).
    2. En quoi ? Les gens de chez JPMorgan doivent bien êtres capable de juger de leurs besoins et de comment les combler au mieux.
    3. Mais je t'en pris recode donc 35Millions de LoC Python en C, ont ce revoie dans 100 ans pour discuter de la suite.

    @wolinn :
    ... quelles sont les différences fondamentales entre 2.7 et 3 qui ont justifié un tel saut ? ...
    Une meilleur gestion d'Unicode (ne plus traiter des String comme de simple tableau d'octet, ...etc), une simplification de l'implémentation (API C, ..etc) et la correction de quelques comportements, syntaxe, API non intuitive.
    Est-ce que ça justifier de développer une branche 3 ?
    Peut-être, mais c'est un choix qui à était fait en estimant que oui et que ce serait de toute façon bénéfique pour le future du langage.
    De toutes façon on parle d'un changement de version majeur donc l'incompatibilité est justifié par le SemVer auquel adhère la PSF depuis toujours.

  9. #9
    Membre éprouvé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    307
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 307
    Points : 1 192
    Points
    1 192
    Par défaut
    Citation Envoyé par defZero Voir le message
    ...
    Heu juste ...Qu'est ce que vous fumez ?
    Vous dites tous les deux ne pas connaitre Python suffisamment et pourtant vous en déduisez que c'est :
    1. Un langage immature et instable.
    2. Pas adapter au projet.
    En français, le mode conditionnel ("...auraient...") est utilisé pour exprimer une hypothèse. Par ailleurs, il n'y a aucune déduction dans ma phrase.
    De loin, je vois seulement une catastrophe coûteuse et je m'interroge sur les causes primaires.
    D'autres langages assurent la compatibilité sur des décennies, tout en continuant à évoluer.

    Citation Envoyé par defZero Voir le message
    @wolinn :
    Une meilleur gestion d'Unicode (ne plus traiter des String comme de simple tableau d'octet, ...etc), une simplification de l'implémentation (API C, ..etc) et la correction de quelques comportements, syntaxe, API non intuitive.
    Est-ce que ça justifier de développer une branche 3 ?
    Peut-être, mais c'est un choix qui à était fait en estimant que oui et que ce serait de toute façon bénéfique pour le future du langage.
    De toutes façon on parle d'un changement de version majeur donc l'incompatibilité est justifié par le SemVer auquel adhère la PSF depuis toujours.
    Merci pour ces précisions.

Discussions similaires

  1. Réponses: 0
    Dernier message: 27/05/2019, 15h39
  2. [XL-2003] Erreur dans une ligne de code que je ne sais pas corriger
    Par phlg77 dans le forum Macros et VBA Excel
    Réponses: 18
    Dernier message: 14/01/2015, 15h21
  3. Le noyau de Linux dépasse les 11.5 millions de lignes de codes
    Par Katleen Erna dans le forum Actualités
    Réponses: 20
    Dernier message: 25/08/2009, 01h05
  4. Transferer 500 millions de lignes
    Par Kikoune dans le forum Oracle
    Réponses: 4
    Dernier message: 26/05/2006, 18h09
  5. [SELECT sur 16 millions de lignes] délai très grand
    Par localhost dans le forum Requêtes
    Réponses: 6
    Dernier message: 22/11/2004, 18h04

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