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) |
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 
Envoyé par flapili
.