De nombreuses bibliothèques Python ont-elles une qualité de code relativement basse?

Question

Modifier: Depuis que cette question a été posée, de nombreuses améliorations ont été apportées aux bibliothèques scientifiques Python standard (le domaine ciblé). Par exemple, le projet numpy a fait de gros efforts pour améliorer la documentation. On peut toujours se demander s’il aurait été possible de régler ces problèmes de manière continue dès le début.

J'ai une question quelque peu hérétique: pourquoi autant de bibliothèques Python ont-elles du code désordonné et ne suivent-elles pas les meilleures pratiques standard? Ou pensez-vous que cette observation est absolument fausse? Comment se présente la situation par rapport à d'autres langues? Je suis intéressé par votre point de vue.

Quelques raisons pour lesquelles j’ai l’impression que la qualité fait défaut:

• Les docstrings manquent souvent ou sont incomplets, même pour l'API publique. Il est pénible lorsqu'une méthode prend * args et ** kwargs mais ne documente pas les valeurs pouvant être fournies.

• Mauvaises pratiques de codage Python, telles que l'ajout de nouveaux attributs en dehors de __ init __ . Ce genre de chose rend le code difficile à lire (ou à maintenir).

• Pratiquement aucune bibliothèque ne respecte les conventions de codage PEP8. Parfois, les conventions ne sont même pas cohérentes dans un seul fichier.

• La conception générale est désordonnée, sans API claire. Il semble que la refactorisation soit insuffisante.

• La couverture la plus faible.

Ne vous méprenez pas, J'aime absolument Python et son écosystème . Et même si je me suis battu avec ces bibliothèques , elles font généralement le travail et je leur en suis reconnaissant . Mais je pense aussi qu’à la fin des tonnes de temps de développement sont perdus à cause de ces problèmes. C’est peut-être parce que Python vous donne tellement de liberté qu’il est très facile d’écrire du mauvais code .

Answer 1

En ce qui concerne la documentation, il n’ya pas que Python. Si un seul facteur empêche l’adoption à grande échelle du logiciel libre, c’est IMHO, le niveau de documentation vraiment épouvantable de la plupart des projets de logiciel libre. Cela commence au niveau du code et s'étend aux documents de l'utilisateur. Puis-je dire à tous ceux qui travaillent sur les logiciels libres:

a) Commentez votre code! Le code auto-documentant n'existe pas!

b) Consacrez au moins 25% du budget temps du projet à la documentation de l'utilisateur final.

Et je sais vaguement de quoi je parle - j’ai moi-même quelques projets de logiciel libre, j’ai contribué à plusieurs autres et j’utilise presque exclusivement du logiciel libre. Hier, j’ai passé plus de 4 heures à essayer de construire un projet majeur de logiciel libre (pas de nom, pas d’exercice), et j’ai échoué à cause de la documentation merdique et contradictoire.

Answer 2

  

Au lieu de cela, les auteurs semblent chacun suivre leur propre convention glorieuse. Et parfois, les conventions ne sont même pas cohérentes avec le même fichier d’une bibliothèque

Bienvenue dans le code merveilleux du monde réel!

FWIW Le code Python que j’ai rencontré n’est ni meilleur ni pire que celui d’une autre langue.

(Bien, mieux que le projet PHP moyen, évidemment, mais ce n'est pas vraiment juste.)

Answer 3

La première chose que vous devez comprendre est que Python n’est pas sorti de la tête de Guido, complètement formé, aux alentours de la version 2.x. Il a grandi au cours des vingt dernières années.

En fait, un certain nombre de choses que vous mentionnez (unittest, par exemple, et PEP-8) n'existaient même pas lorsque certaines des bibliothèques standard ont été écrites pour la première fois.

Vous remarquerez probablement que plus la bibliothèque que vous consultez est ancienne, plus elle est susceptible d'avoir des divergences par rapport aux "meilleures pratiques" actuelles, souvent parce qu'elles sont antérieures à l'adoption généralisée de ces pratiques. Les bibliothèques plus récentes sont plus susceptibles de se conformer aux pratiques actuelles.

De plus, il existe parfois une bonne raison pour ne pas les mettre à jour. Imaginez que vous ayez plusieurs dizaines de milliers de lignes de code écrites dans les bibliothèques Python actuelles. Maintenant, le responsable de l'une de ces bibliothèques décide de changer de bibliothèque pour que les noms de classe et de fonction soient conformes à PEP-8. Maintenant, tous ceux qui ont du code de travail doivent en revisiter d’énormes quantités, de peur que le changement de nom ne casse les choses.

Cela ne veut pas dire que rien ne peut être amélioré dans les bibliothèques Python - il y en a! Mais il y a toujours un compromis à faire entre perfection et réalisation. C’est l’une des raisons pour lesquelles ils affirment que "la simplicité dépasse la pureté".

Answer 4

Cela s'explique par le fait que Python n'est pas sauvegardé par le monde de l'entreprise, tel que Java ou .Net.

Si je souhaite que ma bibliothèque Java soit promue par Sun, je suivrai leurs instructions. Ce n'est pas le cas avec Python. J'écris mon code, les gens le trouvent mieux et il doit évoluer tout seul.

De plus, la plupart des développeurs Python sont issus de C ++, C, Java, .Net, etc. Et ils commencent à écrire du code de production dès le premier jour. Merci à la facilité de Python. Et le cercle vicieux continue.

Même cela m'a pris un mois pour venir à PEP8 et refactoriser mon code.

Answer 5

PEP 8 a changé au fil du temps. Certains modules suivent des recommandations plus anciennes. Vous pouvez voir cela avec PIL, qui utilise des modules tels que "Image". où le module contient une seule classe principale, au lieu des minuscules recommandées pour les noms de modules, et dans les extensions C qui utilisent l'option "c" préfixe, plutôt que le plus moderne " _ " préfixe.

Certaines bibliothèques sont développées par des personnes fortement influencées par les traditions d'autres domaines, tels que Java et C ++. Ces personnes utilisent plus souvent CamelCase au lieu des minuscules recommandées par PEP 8.

Les réponses ne seraient pas complètes sans référence à la loi de Sturgeon : " "Quatre-vingt-dix pour cent de tout est de la merde".

Answer 6

  

Quatre-vingt-dix pour cent des [bibliothèques python] sont crud, mais quatre-vingt-dix pour cent de tout est crud

- Loi sur les esturgeons (paraphrasée)

Answer 7

Il semble que vous en soyez venu à constater que la qualité du code ne répond pas aux attentes que vous attendiez. Peut-être de l'école, des livres de bonnes pratiques ou des développeurs expérimentés.

Après avoir travaillé dans plusieurs sociétés, je me suis régulièrement vu conseiller de faire des tests unitaires, de documenter le code, d’utiliser le contrôle de version / source (tous les bons conseils que j’ai pris), puis de constater que les donneurs de ces conseils suivent rarement les conseils eux-mêmes. .

Je dirais que vous avez la bonne impression que parfois la qualité du code est faible, mais uniquement en fonction de vos attentes. Certainement, numpy et d’autres sont des paquetages très utiles, même s’ils ne sont pas codés conformément au standard auquel vous vous attendiez.

Les normes sont des opinions, et si vous êtes d’avis que les normes sont basses, vous pouvez essayer de les améliorer en les contribuant ou en les acceptant telles quelles et assurez-vous d’écrire du code servant d’exemple à les juniors vous vous retrouvez en charge d'un jour.

Answer 8

Pour ce qui est de matplotlib, il existe un projet visant à améliorer sa "pythoness". - http://www.scipy.org/PyLab

Le problème des bibliothèques scientifiques, c’est qu’elles sont écrites par des scientifiques et non par des développeurs de logiciels professionnels. De plus, ces scientifiques ont l'habitude d'écrire Fortran. La question est la suivante: préféreriez-vous avoir un code fonctionnel ou un code magnifique?

Answer 9

PEP8 est un guide de style et non une exigence de style. Il dit même que vous devriez "savoir quand être incohérent". Personnellement, je n'aime pas certaines des lignes directrices qu'il contient. Je préfère camelCase à snake_case car je suis plus habitué à cela.

Et je ne regarde pas souvent le code source des bibliothèques que j'utilise sauf si c'est absolument nécessaire (comme le débogage). Je préférerais de beaucoup que la documentation de cette bibliothèque soit suffisante pour ne jamais avoir à regarder le code source.

Sérieusement, pourquoi vous souciez-vous vraiment de l'apparence du code source de matplotlib , tant qu'il fait ce qu'il est censé faire?

Je suis d'accord avec vous sur les docstrings manquants (en supposant qu'il s'agisse d'éléments publics plutôt que d'éléments internes), mais ce n'est pas le seul moyen de documenter une bibliothèque.

Answer 10

Je pense que Python souffre d’être hissé trop volontiers sur des personnes qui ne sont pas des programmeurs (par la scolarité ou le commerce) comme solution pour "avoir besoin de programmation faite?" Ici, essayez cet outil simple et évolué.

De la même manière que PHP est devenu un tel succès et avec autant de bibliothèques dont la qualité de code est abyssale (même si la qualité du code Python est moyenne, elle est meilleure que celle de PHP) - l’utilisateur PHP moyen est semblable à l’utilisateur Python moyen. peu d’expérience ou de compétences en programmation et très peu d’incitation à s’améliorer à cet égard - ils ont cherché à atteindre quelque chose, et ils ont peut-être trouvé cela digne d’être partagé avec la communauté sous la forme d’une bibliothèque, mais le plus souvent le travail est fait, ils n’ont aucun intérêt à améliorer le code ou à s’améliorer (en programmation, je veux dire).

La solution pourrait être que les référentiels de bibliothèques Python (tels que PyPI) appliquent des règles plus strictes concernant l'acceptation des paquetages contribués - gérez-le avec un processus de révision destiné à garantir la qualité - de la même manière que les principales distributions Linux ont un processus de révision auparavant. ajouter un paquet à leurs référentiels.

Answer 11

PEP8 n’est que cela, une convention, pas une exigence. Ce serait vraiment dommage si tous les programmeurs python devaient adhérer à un ensemble de règles communes, nous perdrions tout enthousiasme face au moindre problème.

En ce qui concerne les docstrings manquants - oui, ils peuvent aider lors de l'utilisation de l'aide interactive - mais cela ne me dérange généralement pas tant qu'il existe une documentation . J'essaie de ne pas lire le code source des bibliothèques que j'utilise, j'ai tendance à commencer à les modifier (les réécrire).

Answer 12

En ce qui concerne la comparaison avec d’autres langues, je pense que la conception de la langue joue ici un rôle important. Par exemple, dans un langage fortement typé tel que Java, même si la documentation de la bibliothèque est insuffisante, vous pouvez toujours déduire une grande partie des fonctionnalités des signatures de méthode. Aucun * args à gérer.

Answer 13

Que diriez-vous d'une collection d'exemples de bonne documentation logicielle?
De bons exemples pourraient conduire à une amélioration globale un peu plus rapide que la marche aléatoire.
La collection pourrait être divisée en catégories telles que:
doc inline / page d'aide / tutoriel / manuel de référence, page Web / papier, images / aucun.
Chaque entrée doit contenir quelques mots sur pourquoi le critique le trouve bien.
(Où: un coin de stackoverflow?)

Answer 14

nikow: Je ne peux répondre que pour moi-même, la plupart de mes travaux Python (et PHP ou Ruby, tous les langages de "scripting" dynamiques) sont effectués juste pour moi - mais je le publie toujours sur mon site personnel si quelqu'un d'autre le trouve utile, mais je ne passe jamais par aucun processus de documentation ou d'assurance qualité, car tant que cela fonctionne pour moi, je suis heureux.

Answer 15

Ils sont open source. En tant que tels, ils évolueront également avec le temps, s'ils sont suffisamment bons.

C’est l’une des nombreuses beautés de l’open source.

Il est souvent peu logique de rédiger beaucoup de documentation et "bon". code si vous ne savez pas si le projet vivra. Ce ne serait qu'une perte de temps.

Éditer: Bien sûr, écrire un bon code ne ferait jamais de mal la première fois, mais ... peut-être juste "faire le travail". est assez bon dans de nombreux cas. Je pense qu'autrement, nous ne profiterions pas de la vaste gamme d'options en matière de logiciel libre.

Je pense que si suffisamment de personnes agissent de manière spécifique, il pourrait y avoir une explication. Ils ne le font pas seulement au hasard pour vous offenser.

Answer 16

Qualité du code * nombre de commentaires * heure = constante

Choisissez-en deux!

Je n’ai jamais eu de problème avec matplotlib; Je ne peux pas dire que j'ai beaucoup regardé le code - c'est une bonne bibliothèque. Fait ce qu'il est censé faire (gratuitement!)