Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La conception de Python limite son potentiel en tant que langage système fiable et performant
Estime Nathan Murthy, ingénieur logiciel chez Tesla

Le , par Bill Fassinou

66PARTAGES

23  2 
Python est sans doute l’un des langages de programmation les plus populaires et les plus utilisés dans le monde, notamment dans le domaine scientifique et dans la science des données. Mais, selon Nathan Murthy, ingénieur logiciel chez Tesla, sa conception limite son potentiel en tant que langage système fiable et performant, estimant qu’il s’agit d’une chose que beaucoup de développeurs ignorent. Dans un article, il partage tout ce qu’il déteste chez Python, qu’il invite à lire avec une attitude plus claire, plus rationnelle et impartiale.

Selon Nathan Murthy, Python est considéré comme un langage de programmation omniprésent, mais il existe en son sein plusieurs choses qui font de lui un langage de programmation très problématique lorsqu’il s’agit de construire des systèmes distribués fiables et performants. Murthy estime que les problèmes de Python sont évidents pour à peu près tous les ingénieurs qui écrivent du code sérieux, critique pour la mission et de la qualité de production dans l'entreprise moderne. Il suggère de considérer cela avant d'utiliser exclusivement Python pour votre architecture orientée service.

« Mon intention n'est pas de jeter de l'ombre sur les développeurs Python et Python, mais plutôt de mettre en page toutes les considérations à peser avant d'utiliser exclusivement Python pour votre architecture orientée service », a-t-il déclaré. Voici ci-dessous un aperçu des quelques points qu’il aborde dans son billet.

Membres faiblement ou dynamiquement typés

Python est considéré comme un langage de programmation faiblement typé ou dynamiquement typé. Pour lui, la sécurité dactylographique est un élément indispensable pour construire des logiciels fiables dans les grands programmes. Il estime que tous les développeurs devraient se familiariser avec ces termes. Voici un exemple de ce qu’il dit :
Code : Sélectionner tout
1
2
3
4
5
def foo(x):
   if is_valid(x):
       return "hello world"
   else:
       return bar(x)
Pour lui, ce petit bout de code est chargé de problèmes potentiels. Selon lui, si un programmeur visionne ce code pour la première fois, sa question immédiate sera : que fait foo() ?. S’il n’y a pas un test unitaire auquel il peut se référer, ce dernier ne saura pas donner un sens à ce code. Selon Murthy, il est pratiquement impossible d'analyser statiquement cet extrait sans regarder les définitions des fonctions is_valid() et bar(x), et ces méthodes peuvent avoir des références à d'autres méthodes, et ainsi de suite. Le premier problème flagrant est que le programmeur n’a aucune garantie que is_valid() renvoie un type bool.

Le deuxième problème flagrant est que le développeur n’a aucune idée de ce que bar(x) retourne. Est-ce qu'il renvoie un str comme le suggère la première condition ? Si ce n'est pas le cas, alors c’est une méthode qui dans certains cas renvoie une chaîne et d'autres, pas. Si bar(x) retourne un int, alors cela signifie que foo(x) pourrait retourner une chaîne ou un entier. D’après lui, les adeptes de Python appellent ça les types dynamiques et le considèrent comme une caractéristique important du langage, mais il estime que cela peut très vite devenir problématique dans les grandes bases de code.


À ce niveau, Murthy estime qu’au fur et à mesure que la complexité d'une base de code augmente, le coût d'interprétation des membres tapés dynamiquement par les développeurs peut se transformer en goulots d'étranglement énormes pour leur productivité, mais aussi ajouter des frais de maintenance inutiles. Pour Murthy, les humains doivent consacrer du temps soit à déduire manuellement les types, soit à écrire un code standard qui valide les types à chaque site d'appel critique. Il ajoute aussi un autre aspect de la chose.

Il estime qu’en Python, un bon nombre d'erreurs sont découvertes au moment de l'exécution, ce qui est un autre problème. Le fait de ne pas, en l'absence d'une couverture de test parfaite, pouvoir vérifier l'exactitude syntaxique du code de quelqu'un est un problème majeur. « C'est l'une des raisons pour lesquelles les compilateurs ont été inventés : un langage de programmation fortement typé effectuera toutes les vérifications de type nécessaires pour déceler les choses qui ne devraient jamais se produire au moment de l'exécution », a-t-il dit.

Murthy a expliqué que les compilateurs de contrôle de type offrent un niveau supplémentaire de sécurité et de défense à la fiabilité de votre code, et réduisent également le risque d'erreurs logicielles au moment du déploiement. « L'absence de sécurité de type en Python (un peu comme Ruby) devrait être une préoccupation pour quiconque écrit du code sérieux », a-t-il déclaré. Selon lui, pour améliorer le contrôle de type statique en Python, les développeurs ont créé des bibliothèques, mais qui ne sont pas souvent utilisées.

Cela serait dû au fait qu’elles n'appartiennent pas à la chaîne d'outils standard ou parce que leur utilisation nécessite souvent un effort significatif pour investir du temps dans la mise à jour du code existant en ajoutant des notes en standard si la sécurité du type est traitée comme une réflexion secondaire.

Le verrouillage de l'interprète global

Selon Murthy, les logiciels modernes sont multithread et multicore, et donc presque tous les langages de programmation modernes offrent des primitives de concomitance. Il estime que Python est livré avec un module de threading, mais en raison de la façon dont l'interpréteur Python est implémenté, il ne peut jamais exécuter qu'un seul thread à la fois. Ceci est dû au fameux Global Interpreter Lock (GIL). Les ordinateurs possédant aujourd’hui plusieurs processeurs, le GIL introduit un comportement litigieux entre les processeurs pour les tâches liées au CPU. Ainsi, il impose une contrainte aux programmes concurrents qui sont lourds en calcul.

Performance

D’après ce que dit Murthy, Python est relativement lent par rapport aux langages de programmation qui fonctionnent plus près du système d'exploitation. La concomitance multithread est une faiblesse de Python pour les tâches liées au CPU, de même que le traitement parallèle dans des tests similaires. La vitesse brute de Python lorsqu'il s'agit d'exécuter une variété de tâches de calcul ou de tâches liées aux E/S n'est pas stellaire comme le démontrent plusieurs benchmarks standards. Il a aussi déclaré que Python souffre également d'une surcharge d'invocation de fonction très élevée.

Selon lui, il existe des implémentations telles que PyPy qui sont fondamentalement plus rapides que l'implémentation de référence de CPython, mais qui n'offrent pas la même étendue de bibliothèques déjà supportées par l'écosystème CPython. « Les limites de performance de Python le rendent mal adapté aux systèmes de traitement en temps réel ou aux systèmes basés sur les flux qui déplacent ou manipulent de grands volumes de données sur plusieurs machines avec une faible latence, ce qui est pratiquement tautologique pour les ingénieurs construisant des systèmes distribués à grande vitesse », a-t-il déclaré.

Le Grand Schisme : Python2 vs Python3

Murthy suggère que si vous faites du développement sur Mac ou Ubuntu, vous avez probablement déjà installé Python 2.7. Si c’est le cas, il estime qu’il y a de fortes chances que lorsque vous avez commencé à programmer en Python, personne ne vous ait parlé de Python 3. Et donc, si vous parcouriez Python 2 sans vous en rendre compte, vous avez peut-être été surpris d'apprendre que certains programmes Python fonctionnent bien sur les machines de vos collègues, mais que sur votre machine, un tas d'erreurs de syntaxe apparaissent.

Ce qu’il appelle le schisme de Python serait apparu en 2008 avec la sortie de Python 3. Selon lui, beaucoup pensaient que ce serait l'avenir de Python, mais en réalité, ce n'était pas le cas. « Plusieurs projets ont été développés sous Python 2. J'ai moi-même travaillé sur une base de code pendant trois ans qui n'a fonctionné que sur Python 2.4. La migration vers Python 3 ou 2.7 était impossible à cause des bibliothèques spécifiques aux fournisseurs que nous utilisions », a-t-il déclaré, ajoutant que ces points douloureux ne sont pas uniques.

Il a déclaré qu’au fil du temps, la communauté des développeurs a créé des outils comme 2to3, 3to2, et six, qui étaient tous des gestes bien intentionnés pour apporter une amélioration à la compatibilité syntaxique entre les bibliothèques, mais n'étaient pas des solutions parfaites, car il y a toujours du code qui ne peut être converti. Ainsi, selon lui, Python a des limitations sur l'écriture de code propre en amont et en aval du code compatible. Ces limites ne sont pas anodines, surtout pour les équipes qui possèdent des logiciels essentiels à leur mission.

Encapsulation et conditionnement

Ici, Murthy avance que les abstractions de classes fuient en Python. « N'importe qui peut accéder au code de presque n'importe où », a-t-il déclaré. Les classes peuvent avoir des membres qui ne sont pas sûrs lorsqu'ils sont exécutés en dehors de leur définition de classe. Par convention, les membres avec un seul trait de soulignement en tête sont considérés comme “protégés”, et les membres avec un double trait de soulignement en tête sont considérés comme “privés”. Cependant, il dit que Python n'a pas de véritable modèle de confidentialité. Ainsi, au lieu de cela, l'interpréteur recourt à la manipulation pour protéger les espaces de noms lors de l'utilisation de l'héritage, mais permet toujours l'accès aux membres mutilés.

Système de construction désorganisé

Selon Murthy, construire un projet avec Python et importer des dépendances peut être compliqué. Si vous faites du développement logiciel sérieux en Python, c'est presque toujours compliqué. Pour donner des exemples de ce qu'il dit, il utilise la bibliothèque numpy, un module de programmation numérique populaire qui enchante les développeurs à la recherche de l'apparence de MATLAB, Octave ou R. Murthy a conclu à cette étape que le gonflement et la pilosité de l'installation des paquets Python est épouvantable.

« Juste pour faire une simple déclaration d'importation d'une ligne, numpy nécessite 285 Mo à 529 Mo de code de soutien », a-t-il dit. L'espace disque est bon marché de nos jours, et il y a des choses bien pires dans le monde que les images de conteneurs gonflés. Cependant, le fait est que construire des projets Python sur une infrastructure de déploiement moderne peut être un processus très désorganisé et impur du point de vue de l'intégration continue et de la livraison continue. Les outils d'installation des dépendances Python placeront les fichiers et les linkers dispersés dans votre système de fichiers.
Pour conclure, Murthy a déclaré qu’au niveau le plus fondamental, Python est un langage de script, comme Perl, Ruby ou JavaScript.

C'est un langage interprété. Il est idéal pour les petits programmes rapides et sales qui exécutent des tâches séquentielles à filetage unique. Il s'est imposé comme une marque puissante au sein de la communauté des chercheurs et des programmeurs scientifiques. Il y a donc incontestablement une place pour lui en tant qu'outil approprié en fonction de l'emploi. Toutefois, choisir d’utiliser exclusivement Python dans les entreprises utilisant des systèmes distribués critiques en production s'accompagne de toutes sortes de compromis considérables.

Source : Nathan Murthy

Et vous ?

Trouvez-vous les arguments de Nathan Murthy pertinents ou pas ? Pourquoi ?
Quel est votre avis sur le sujet ?
Partagez-vous les mêmes points de vue que Nathan Murthy à propos de Python ? Pourquoi ?
Comme Nathan Murthy, pensez-vous que Python ne soit pas adapté pour construire des systèmes distribués fiables et performants ? Pourquoi ?

Voir aussi

Microsoft a intégré Python 3.7 par défaut dans la MàJ Windows 10 mai 2019 de son système d'exploitation

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 rencontré après cette date

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é

Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans plus d'une centaine d'études scientifiques publiées depuis 2014

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/11/2019 à 14:04
Citation Envoyé par flapili Voir le message
il ne faut pas reprocher à quelque chose un choix de conception, idem pour le typage ...
Je dirait a la fois oui et non. Il n'est, en effet, généralement pas pertinent de parler d'un langage en dehors de son domaine d'utilisation normal. Cependant Python et JavaScript ont en commun d'être des langage dont l'utilisation c'est développé bien au delà de leur domaine d’origine et le but ici n'est pas de dire du mal de Python en général mais de Python utilisé là où on devrait avoir recours a un langage système.

En dehors de cela, certains choix de conception peuvent tout a fait être criticables. Si tous les choix de conception de Python 2 avaient été exempts de reproche, il n'y aurait pas eu de Python 3.
13  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/11/2019 à 16:18
Citation Envoyé par CaptainDangeax Voir le message
Il commence par écrire une fonction toute sale, et puis il vient reprocher au langage de lui avoir laissé écrire une fonction toute sale. Ce n'est pas le langage qui a écrit une fonction toute sale, c'est lui...
Forcément pour la démonstartion, il a pris un cas simple, où l'erreur est évidente. Mais tout l’intérêt du typage, c'est justement d'attraper des erreurs qui ne sont pas forcément facile débusquer, parce que le développeur qui ne fait pas d'erreur, ça n'existe pas.

Citation Envoyé par CaptainDangeax Voir le message
Il reproche au langage de ne pas être fortement typé. C'est sa définition. Si ça ne convient pas, on utilise autre chose.
Il reproche au langage son manque de performances. Si on veut de la performance, on ne programme pas dans un langage interprété, on programme dans un langage compilé, voire en assembleur si on veut VRAIMENT de la performance.
Justement sa diatribe vise particulièrement l'utilisation de Python dans le domaine système où il n'est pas adapté, ce qui est malheureusement de plus en plus le cas.
En fait dès qu'un langage gagne en popularité, notamment au niveau des débutants, il y a toujours des gens qui sont tentés de l'utiliser partout sans se poser les bonnes question. Ça a été le cas du VB et du Java à une époque, maintenant c'est le JavaScript et le Python.

Citation Envoyé par CaptainDangeax Voir le message
Il reproche le schisme qu'il y a eu entre Python2 et Python3. Il faut juste se dire que c'est un nouveau langage et que tout programme mérite un certain niveau de maintenance si on veut le garder dans le temps.
La plupart des langages d'un age similaire au Python, voire bien plus vieux, ont pourtant su gérer leur transition bien mieux. Java et C++ par exemple ont su évoluer sans briser lourdement l'écosystème.
Perl a choisi de changer de nom pour marquer la clairement la rupture.

Citation Envoyé par CaptainDangeax Voir le message
C'est d'autant plus vrai que les langages finissent pas être frappés d'obsolescence. Qui programme encore en Fortran, en ADA, en Cobol, en dBase-clipper, en forth ? Qui, surtout, démarre un nouveau projet avec un langage ancien ?
- Cobol : encore très utilisé dans le bancaire, même si c'est vrai que c'est généralement pour des base code existantes complexes
- Fortan : Pas mal de scientifique en font encore y compris pour du neuf.
- Ada : est toujours utilisé dans des domaine particulier qui nécessitent de la sécurisation

Pour Forth en effet c'est plus compliqué, mais beaucoup de langage bien plus ancien que le Python comme le C, C++ ou le LISP se portent toujours bien.
12  0 
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 28/11/2019 à 17:09
Citation Envoyé par CaptainDangeax Voir le message
Il commence par écrire une fonction toute sale, et puis il vient reprocher au langage de lui avoir laissé écrire une fonction toute sale. Ce n'est pas le langage qui a écrit une fonction toute sale, c'est lui...
On parle d'applications critiques là, le plus efficace pour s'assurer que l'on ne peut pas faire des erreurs de programmation grossières, c'est que le langage ne les permette pas.

C'est un peu comme dire que poser un verre de café sur un clavier d'ordinateur n'est pas dangereux, il suffit de faire en sorte que les gens ne soient pas maladroits.
11  1 
Avatar de CaptainDangeax
Membre éclairé https://www.developpez.com
Le 28/11/2019 à 14:29
La communication de ce M. Murphy est limite trollesque, je trouve.

Il commence par écrire une fonction toute sale, et puis il vient reprocher au langage de lui avoir laissé écrire une fonction toute sale. Ce n'est pas le langage qui a écrit une fonction toute sale, c'est lui...
Il reproche au langage de ne pas être fortement typé. C'est sa définition. Si ça ne convient pas, on utilise autre chose
Il reproche au langage son manque de performances. Si on veut de la performance, on ne programme pas dans un langage interprété, on programme dans un langage compilé, voire en assembleur si on veut VRAIMENT de la performance.
Il reproche le schisme qu'il y a eu entre Python2 et Python3. Il faut juste se dire que c'est un nouveau langage et que tout programme mérite un certain niveau de maintenance si on veut le garder dans le temps. C'est d'autant plus vrai que les langages finissent pas être frappés d'obsolescence. Qui programme encore en Fortran, en ADA, en Cobol, en dBase-clipper, en forth ? Qui, surtout, démarre un nouveau projet avec un langage ancien ?
15  6 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 28/11/2019 à 17:24
Citation Envoyé par defZero Voir le message
MDR, Le mec c'est "Captain Obvious" ressuscité
L'ingénieur de chez Tesla il l'as eu comment sont poste ?
Mr MURPHY Nathan, un nom qui restera dans les annaux .
Je crois que vous vous méprenez lourdement sur l’intention du message. Dès la première phase l'article est clair sur son intention :
Python est vu comme un langage de programmation à tout faire; cependant sa conception limite son potentiel en tant que langage sytème fiable et à haute performance. Malheureusement, tous les programmeurs ne sont pas au courant de ses limitations
Il ne prétend pas démontrer quoi que ce soit de nouveau, il déplore juste que la forte popularité de Python fait qu'il est parfois surestimé.
Bref cet article ne s'adresse pas aux experts qui connaissent bien les limitation du langage, mais à ceux qui sont tenté de faire du Python partout parce qu'il ne connaissent pas assez les autre langages, ou aux décisionnaire pas forcément au fait de tous les détails techniques, pour leur expliquer pourquoi ça n'est pas une bonne idée de l'utiliser partout.
9  1 
Avatar de Fagus
Membre actif https://www.developpez.com
Le 28/11/2019 à 15:42
Je ne comprends pas très bien cette querelle sur le typage de python. Oui, ce n'est pas typé par défaut et donc on peut faire des erreurs grossières de typage, mais c'est pratique pour écrire un script sale à l'arrache. Pour le code sérieux on peut utiliser le typage optionnel (mypy, pycharm).

il y a d'autre problèmes plus ennuyeux : si on veut programmer sur du desktop, la distribution est vraiment compliquée pour obtenir un installateur en un fichier pour l'utilisateur final, ce qui est vraiment un gros problème (un de mes logiciel open source de desktop en python a juste abandonné la distribution de binaires pour windows car leur code plante les outils tiers qui assemblent tout le code, les dépendance et un interpréteur et que personne n'a de solution...). Je regrette beaucoup que les dév de python n'intègrent pas à python les outils pour déployer simplement (genre comme delphi ou java)
4  0 
Avatar de rattlehead
Membre expérimenté https://www.developpez.com
Le 28/11/2019 à 15:10
Citation Envoyé par Bardotj Voir le message
Ça n'est pas le souci. c'est que tu supposes que bar(x) peut renvoyer une chaine ou autre chose éventuellement un int vu qu'il n'y a pas de type défini au niveau de la définition de foo(x).
en gros dans un langage "standard" tu aurais function foo(x) as string ou string foo(x). Là tu ne sais pas.
3  0 
Avatar de Steinvikel
Membre chevronné https://www.developpez.com
Le 28/11/2019 à 22:33
Cette histoire de typage, je la vois souvent pour des histoires de "sécurité", pour contenir des erreurs ou des incohérences. Mais l'effet phénoménal à notre époque, c'est de permettre au compilateur de fait un tas d'optimisations bien plus pertinentes !

Un exemple typique de l'utilité de pondre une ligne de code généreusement explicitement, écrite sur un langage typé et compilé.
NB : son but était de faire tourner un jeu sur un CPU sans faire appel à la RAM, le HDD, etc. en s'appuyant intégralement sur le processeur et son cache --> MSP 430-FR5849 (16 bit, 16 MHz, 66 ko, 10$)

Vous voyez sur ce court extrait de 2min, la programmation en C++ d'un space-invaders, la problématique est la suivante :
Il pond du code (à gauche) ...et une fois compilé, le code asm généré est gigantestque (à droite).
Que peut-il faire pour permettre à son code asm de "maigrir" ? --> déclarer sa variable statique de manière explicite avec "const" car elle est ici utilisé comme constante, et non comme une variable.
conséquence --> l'overhead de 350 instructions assembleur se transforme en simple 6 instructions --> merci à l'optimisation du compilo !

https://youtu.be/zBkNBP00wJE?t=1599
3  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 29/11/2019 à 6:52
Au final, il s'agit davantage d'un reproche sur les cas d'utilisation du langage que sur le langage en lui-même.
L'auteur devrait tout de même mieux formuler ses propos car le tout peut laisser croire que Python est un "mauvais" langage. Ce n'est pas le cas. C'est juste un outil à utiliser à bon escient.
2  0 
Avatar de ParseCoder
Membre averti https://www.developpez.com
Le 28/11/2019 à 14:36
"Langage système"!!! Ai-je bien lu! Ah oui.
1  0