Discussion :

[Bill Fassinou]

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

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 - Visualiser dans une fenêtre à part

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

[matthius]

Passez de Python et Matlab à Julia, de Ruby à Crystal, de C à RUST.

[flapili]

python n'as jamais eu cette prétention, par contre il y a clairement de la mauvaise fois ... que ce soit sur python 2 ou encore la taille sur le disque"

Python n'a pas de véritable modèle de confidentialité

il ne faut pas reprocher à quelque chose un choix de conception, idem pour le typage ...

[Uther]

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.

[CaptainDangeax]

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 ?

[emixam16]

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

Complétement d'accord. Surtout que même avec un langage fortement typé, si je veux écrire une fonction `is_valid(x)` qui retourne un `struct chou_fleur*`personne ne va m'en empêcher... Un mauvais code reste un mauvais code dans n'importe quel langage. Et il n'y a aucun langage généraliste avec lequel je ne puisse pas écrire de code pourri, donc c'est minable de taper sur le python pour ça.

Quant au schisme python2/3, on commence à avoir pas mal de recul et la transition est quasiment faite partout vers python 3. En tout cas ce sera rapidement le cas avec la mort programmée de python2.

Pour les performances, évidemment que le python n'est pas adapté à tout. Mais pour un bon nombre de scénarios ce n'est pas un problème. Pour d'autres, comme souvent en Machine Learning, les API sont en python pour être facilement accessibles et les opérations sensibles aux performances sont écrites en C.

Bref, évidemment que le Python n'est pas fait pour tout (personnellement j'ai une sainte horreur de l'absense de typage en Python et je travaille dans des systèmes ou la performance est reine). Mais ça ne signifie pas qu'on ne puisse rien faire de sérieux/propre en python

[Betameche]

Complétement d'accord. Surtout que même avec un langage fortement typé, si je veux écrire une fonction `is_valid(x)` qui retourne un `struct chou_fleur*`personne ne va m'en empêcher... Un mauvais code reste un mauvais code dans n'importe quel langage. Et il n'y a aucun langage généraliste avec lequel je ne puisse pas écrire de code pourri, donc c'est minable de taper sur le python pour ça.

Je ne suis pas vraiment d'accord avec ta remarque pour deux raisons.
Premièrement, l'exemple de code donné n'est pas du code python pourri. Une fonction qui fait une vérification de validité et retourne une valeur par défaut ou un résultat sur la valeur passée c'est assez commun dans un code. Pour faire la présentation de ce qu'il trouve problématique, je trouve qu'il choisit un code assez simple sans chercher des usages inhabituels, et sous une forme que l'on retrouve partout. D’ailleurs le code de Bardotj est plus sale de mon point de vu. Après on peu me rétorquer qu'il n'y a pas de vérification du type de l'entrée …

Deuxièmement, même dans un langage peu typé comme le C/C++ le code ne compilerait pas dans la plupart des cas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
<source>:14:16: error: could not convert 'is_valid(i)' from 'choux_fleur' to 'bool'
 
  14 |       if(is_valid(i))
      |           ~~~~^~
      |                     |
      |                choux_fleur

Sauf dans le cas des pointeurs, le langage permettant de vérifier directement par if s'il est un NULL/nullptr ou pas.
Ce choix est aussi critiquable, même si c'est un choix de conception. Rust par exemple a fait un autre choix, le if ne prenant q'un type bool comme opérande.

Pour le reste je suis plutôt d'accord avec defZero, avec comme réserve qu'il me semble légitime de critiquer un langage dans ses domaines d'applications en plus des domaines pour lesquels il a été créé.

[Uther]

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.

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.

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.

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.

[thanjuzo]

Qui programme encore en Fortran, en ADA, en Cobol, en dBase-clipper, en forth ?

Moi ... En Fortran sur du legacy. Les colboliens existent, et pas sur du legacy (il m'arrive d'en fréquenter).

[magatst]

Et que dire des Bugs d’indentation !!!

[ParseCoder]

"Langage système"!!! Ai-je bien lu! Ah oui.

[CaptainDangeax]

"Langage système"!!! Ai-je bien lu! Ah oui.

Il faut s'entendre sur ce qu'est un langage système. Si c'est un langage pour coder un noyau, un driver matériel, etc, c'est clairement inadapté ! Si c'est un langage pour écrire toute la glue qui fait le système tenir ensemble, genre des tâches planifiées lancées par CRON, ça fait le job, comme bash ou perl...

[Uther]

Il faut s'entendre sur ce qu'est un langage système. Si c'est un langage pour coder un noyau, un driver matériel, etc, c'est clairement inadapté ! Si c'est un langage pour écrire toute la glue qui fait le système tenir ensemble, genre des tâches planifiées lancées par CRON, ça fait le job, comme bash ou perl...

En effet, une partie du problème vient du fait qu'il n'y a pas de définition officielle du terme langage système.
Cependant le premier cas est le plus couramment admis. Pour le second on parle généralement plutôt de langage de script.

[disedorgue]

Il faut s'entendre sur ce qu'est un langage système. Si c'est un langage pour coder un noyau, un driver matériel, etc, c'est clairement inadapté ! Si c'est un langage pour écrire toute la glue qui fait le système tenir ensemble, genre des tâches planifiées lancées par CRON, ça fait le job, comme bash ou perl...

Pour moi, ici, on est dans le raccourci d'expression de la langue française (voir autre langue)...


Dans le principe, quand on parle de système, on est dans le bas niveau (vraiment le très bas), ce qui fait que l'on voit des langages tel que C ou assembleur...

Et on a ce que l'on appelle ou devrait appeler les langages de l'administration système et ici, cela fait intervenir des langages de script tel que les shell, perl, python...

Et bien sur, des langages tels que java et/ou php n'ont rien à faire dans ces catégories, ce sont ce que je nommerais plus des langages applicatifs, de présentation ou d'administration fonctionnelle.

Après, rien n'interdit au langage du bas de monter vers les niveaux supérieurs mais l'inverse est une aberration.

Enfin, c'est mon point de vue, en aucun cas, je ne critique un langage en particulier.

[Bardotj]

Je trouve son code super pas propre, je vais faire du pseudo code, ne faisant pas tout les jours du python.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
def foo(x):
  if is_valid(x):
    return "hello world"
  else:
    return bar(x)

Devrait être :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
def foo (x):
  result = valeur
  if is_valid(x):
    result = "hello world"
  else:
    result = bar(x)
 
  return result

Car oui le code est fait pour être lisible facilement, maintenable facilement. L’optimisation c est au compilo/interpréteur de la faire surtout sur l utilisation des primitives languages. On est clairement pas dans un algo compliqué ou l on cherche a améliorer la complexité (au sens algo/math).

Étant sans javascript pas d intent dans le code j ai sauté une ligne pour le return pour signifier qu il n est pas dans le else. Il s agit néanmoins bien d’une instruction appartenant a foo.

[rattlehead]

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

[Fagus]

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)

[L33tige]

Je trouve son code super pas propre, je vais faire du pseudo code, ne faisant pas tout les jours du python.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
def foo(x):
  if is_valid(x):
    return "hello world"
  else:
    return bar(x)

Devrait être :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
def foo (x):
  result = valeur
  if is_valid(x):
    result = "hello world"
  else:
    result = bar(x)
 
  return result

Car oui le code est fait pour être lisible facilement, maintenable facilement. L’optimisation c est au compilo/interpréteur de la faire surtout sur l utilisation des primitives languages. On est clairement pas dans un algo compliqué ou l on cherche a améliorer la complexité (au sens algo/math).

Étant sans javascript pas d intent dans le code j ai sauté une ligne pour le return pour signifier qu il n est pas dans le else. Il s agit néanmoins bien d’une instruction appartenant a foo.

Chacun sa définition de lisibilité, perso je trouve le premier cas bien plus lisible.

Sinon il reste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
def foo(x):
  return is_valid(x) ? "hello world" : bar(x)

[merill]

Chacun sa définition de lisibilité, perso je trouve le premier cas bien plus lisible.

Sinon il reste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
def foo(x):
  return is_valid(x) ? "hello world" : bar(x)

on peut aussi ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

foo = lambda x: "hello world" if is_valid(x) else bar(x)

non?

edit: corrigé

[Pyramidev]

is_valid(x) ? "hello world" : bar(x) n'est pas une syntaxe valide en Python.
La syntaxe correcte est : "hello world" if is_valid(x) else bar(x).