Les raisons en sont notamment sa lisibilité et sa maintenabilité, la structure modulaire, dynamique et portable, la programmation flexible, son apprentissage facile et les supports d'apprentissage, les structures de données conviviales, la productivité et la vitesse qu’il permet, et, plus important encore, le support communautaire.
Parler de code lisible en python, bof pourquoi pas, mais concernant la maintenabilité, je ne suis absolument pas d'accord. A mon avis la seule raison pour laquelle python est si utilisé est qu'il est très facile de coder un truc qui marchote sans avoir une très grande connaissance du langage (en plus de tous les modules dispo qui machent beaucoup le travail). C'est effectivement le point fort de python.
Très peu de langages peuvent égaler la capacité de Python à se conformer au style de codage d'un développeur plutôt que de le forcer à coder d'une manière particulière.
Ca par contre je trouve que c'est un mensonge digne d'un commercial :). Ce que je reproche à Python, c'est justement une certaine rigidité qui t'oblige à faire "de la bonne façon" (pythonic comme tu dis plus haut). Bien souvent, quand je développe en Python, je suis obligé de faire des trucs plus ou moins tordus que je fais de façon plus simple et concise en ruby. L'absece de switch/case par exemple est problématique de mon point de vue: un enchainement de if/else if, emn plus d'être rébarbatif, n'est pas très élégant et ne répond pas au même besoin: et si on veut simuler un switch/case, il faut contourner et on se retrouve avec un probramme qui n'est plus orcément très lisible ( je n'utilise pas souvent cette structure, mais il y a des cas, notamment quand on parse des données, ou c'est bien plus lisible et plus pratique que le reste. Un switch/case ne permettant de n'appeler qu'une fonction/méthode me suffirait ...
Vous pouvez profiter de la promesse de Python d'offrir aux développeurs un environnement non contraignant pour coder dans le style le mieux adapté à une situation particulière et de rendre le code plus lisible, testable et cohérent.
Je trouve au contraire que Le changement de paradigme au fil de l'eau (surtout dans une fonction/méthode de plusieurs dieaines de lignes (comme c'est courants chez beaucoup de "développeurs" python ) nuit à la lisibilité du code. Pour ma part je m'efforce de faire des fonctions courtes, et i je dois faire appel par exemple à un paradigme fonctionnel dans du code plutôt objet, j'essai de faire une abstraction et de l'encapsuler dans une méthode qui décrit clairement ce que je fais (les list comprehension sont un peu difficile à déchiffrer, même quand on en a l'habitude).
Il n'y a aucune règle qui dit que vous ne pouvez pas combiner les styles selon vos besoins
La lisibilité ? Rappel: on ne code pas pour la machine, mais on code pour que les autres puissent relire ...
# Pour ma part je ne suis pas d'accord avec certains des points mentionnés.
Posté par totof2000 . En réponse au journal L/D·es différents paradigmes de programmation en Python. Évalué à 5.
Parler de code lisible en python, bof pourquoi pas, mais concernant la maintenabilité, je ne suis absolument pas d'accord. A mon avis la seule raison pour laquelle python est si utilisé est qu'il est très facile de coder un truc qui marchote sans avoir une très grande connaissance du langage (en plus de tous les modules dispo qui machent beaucoup le travail). C'est effectivement le point fort de python.
Ca par contre je trouve que c'est un mensonge digne d'un commercial :). Ce que je reproche à Python, c'est justement une certaine rigidité qui t'oblige à faire "de la bonne façon" (pythonic comme tu dis plus haut). Bien souvent, quand je développe en Python, je suis obligé de faire des trucs plus ou moins tordus que je fais de façon plus simple et concise en ruby. L'absece de switch/case par exemple est problématique de mon point de vue: un enchainement de if/else if, emn plus d'être rébarbatif, n'est pas très élégant et ne répond pas au même besoin: et si on veut simuler un switch/case, il faut contourner et on se retrouve avec un probramme qui n'est plus orcément très lisible ( je n'utilise pas souvent cette structure, mais il y a des cas, notamment quand on parse des données, ou c'est bien plus lisible et plus pratique que le reste. Un switch/case ne permettant de n'appeler qu'une fonction/méthode me suffirait ...
Je trouve au contraire que Le changement de paradigme au fil de l'eau (surtout dans une fonction/méthode de plusieurs dieaines de lignes (comme c'est courants chez beaucoup de "développeurs" python ) nuit à la lisibilité du code. Pour ma part je m'efforce de faire des fonctions courtes, et i je dois faire appel par exemple à un paradigme fonctionnel dans du code plutôt objet, j'essai de faire une abstraction et de l'encapsuler dans une méthode qui décrit clairement ce que je fais (les list comprehension sont un peu difficile à déchiffrer, même quand on en a l'habitude).
La lisibilité ? Rappel: on ne code pas pour la machine, mais on code pour que les autres puissent relire ...