Discussion :

[Bill Fassinou]

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.

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

[tutosfaciles48]

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)

[abriotde]

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é.

[defZero]

@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.

[hotcryx]

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!

[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]

...
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 ?).

[defZero]

@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.

[wolinn]

...
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.

@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.