Yeah, on a des fannnnnnns !
Ça fait quelques semaines que je me suis mis à python. J’ai commencé par des scripts (tendance sysadmin oblige) puis je me suis lancé dans des choses un (petit) peu plus importantes, notamment influencé par les cours sur la POO. Je tiens d’ailleurs à vous féliciter sur ce point, même le site du zéro n’avait jamais réussi à me les faire vraiment comprendre. Et donc, comme tout débutant qui se respecte j’essaie de faire de mon petit programme un chef d’œuvre de perfection (et il y a du boulot).
Le truc, c’est que je ne connais rien aux bonnes pratiques en python (comment commenter utilement les fonctions, les conventions de nommage, les jolies façons de coder, etc…). Je suis à la recherche d’exemples sûrs.
Connaissez-vous des librairies ou applications au code exemplaire dont je pourrais m’inspirer tant au niveau du code lui-même que de l’API ou de la doc ?
(Allez, vous devez bien en avoir à l’esprit ^^)
Bref, merci (si c’est pas pour ça c’est pour le reste) et bonne soirée !
Cher [censored],
Être placé au dessus du site du zéro provoque chez moi une érection incontrôlée. Merci.
Bonne nouvelle, il n’existe rien de tel que le code parfait, et des tas d’excellents dev font de la merde quotidiennement, ce qui permet de relativiser face à son niveau.
Maintenant, si je devais donner des exemples de code et doc dont on peut s’inspirer, je dirais :
- les modules strings et structs de batbelt sont faciles pour commencer et propres. Le reste est moins bon car la lib est encore en alpha (mais intéressante si tu as le temps) et il n’y a pas de doc. La doc de zerobin en revanche est très bonne pour les utilisateurs (mais le code, bien que pas mauvais, n’est pas un exemple de best practice).
- path.py a un code est très accessible qui tient dans un seul fichier, mais on peut passer beaucoup de temps dessus. Il est plein de subtilités. Les tests unitaires aussi sont simples à aborder.
- peewee a un code compliqué et abstrait mais très propre. Bien si on veut travailler ses connaissances sur l’architecture de code.
- requests. Niveau avancé, mais très abordable pour un si gros projet. Excellent pour voir comment s’articule un gros truc en plein de tout petits morceaux bien techniques. La doc technique est d’un bon niveau.
- bottle : ne regarde surtout pas le code. Mais leur doc technique est exceptionelle.
- le module CSV de la lib standard. Il est dans ton install Python (chez moi dans /usr/lib/python2.7/csv.py). Pas mal pour voir comment ça marche en interne, et c’est un petit module pas prise de tête. Ça permet aussi de voir que ceux qui suivent les meilleurs pratiques sont pas forcément ceux qui les prêchent.
Petit rappel ceci dit : même un bon code a toujours des lacunes. Si tu prends n’importe quel bout de ces libs et le mets sur un forum, tu auras toujours un râleur pour venir débattre sur ce qu’il aurait valu mieux faire.
De plus, d’une manière générale, les gens qui publient de bons codes font des trucs un peu plus compliqués qu’un simple script. Donc tu auras toujours à froncer un peu les sourcils pour comprendre. C’est normal, ne perd pas courage.
A éviter niveau code : django, bottle, twisted et les frameworks web en général. Les gros projets avec des bindings C de types sqlalchemy, qt, wx , etc. Car là on rentre dans un autre monde.
J’ai lu un bouquin qui s’appelle “Clean Code” de Robert Martin qui donne quelques conseils de bonnes pratiques pour écrire du bon code. ça implique de parler de la longueur des classes, du noms des variables/fonctions, des tests unitaires, des commentaires etc.
Ce sont quelques conseils intéressants…
Concernant les conventions, le mieux ça reste de jeter un coup d’œil au PEP8 : http://www.python.org/dev/peps/pep-0008/. Une grande majorité des devs python suivent ces conventions (pas forcément à la lettre, mais assez proche).
Quand j’aurai des heures sans rien à faire (plus que 35 ans avant la retraite…) je regarderai votre liste, ça a l’air intéressant !
“des tas d’excellents dev font de la merde quotidiennement” => C’est du vécu ? ;)
Merci pour les liens ! Ca fait quelques semaines que je m’essaye au python aussi, donc j’vais regarder tout ça de plus prêt. Pour l’instant le plus gros reproche que je peux faire à ce langage, c’est que c’est dégueulasse. J’veux dire, c’est moins facile qu’avec d’autres de pondre du code lisible et agréable à lire.
La référence Python : PEP 8.
@kontre: oui c’est du vécu ^^
@Eylith: marrant, moi j’ai l’expérience inverse.
Sinon pour le PEP8, c’est important, mais c’est pas suffisant pour du bon code. On peut écrire un code illisible PEP8 compliant. Et on peut écrire un code très lisible, mais dégueulasse.
Un code propre, c’est :
– lisible
– compréhensible
– qui marche
– facile à comprendre pour un nouveau venu
– facile de se balader dedans (bien organisé)
– facile à modifier
Le moyen que j’ai utilisé pour me mettre facilement à la norme PEP008 est d’utiliser un plugin qui effectue le check à la volée. Sous SublimeText il y en a plusieurs.
@Eylith je pense que c’est du troll
Sous sublime texte, sublime linter est de loin le meilleur plugin pour ça. Recommandé ++.
Je parlais de pep8 uniquement pour les conventions, c’est clair que ça ne suffit pas pour écrire du bon code. D’ailleurs, si vous récupérez un code mal formaté, l’utilitaire autopep8 permet de donner un bon coup de balai.
L’éditeur spyder intègre pep8 et pyflakes pour les checks, ça évide déjà bien les grosses bourdes. Sublime Text j’ai pas encore réussi à essayer pour de vrai, de prime abord l’interface ne m’inspire pas…
@Axel R. En parlant de noms de variables, tu me rappelle un débat houleux sur le forum des dev-pros.
Ils étaient tous d’accord pour condamner les aa, bb…
Mais quand tu fait une recherche dans le code, il vaut mieux chercher des aa, que des a. Ils sont moins nombreux.
@Eylith. Si l’assembleur est une trousse de chirurgien, et le PHP une cuillère en bois; le python est une tronçonneuse.
Alors forcément, c’est un peu moins précis.
Mais qu’est-ce que ça abat !!!
@roro Certes, ‘aa’ est un peu mieux que ‘a’ comme nom de variable. Mais ‘row_index’ (par exemple) c’est top.
Au boulot on développe un programme en C avec des fichiers de 50000 lignes (pour une 20aine de fonctions max) remplis de w, w1, w2, w3, a, b, c, avec peu de commentaires et zéro tests. Ben j’ose pas y toucher. Je dois avouer qu’il y a aussi des variables avec des noms corrects, mais y’en a 600 lignes au début du fichier…
avec Vim ya https://github.com/tcolombo/dotvim qui marche terriblement bien + vim-flake8 https://github.com/nvie/vim-flake8 – . testé & approuvé :)
Dans la prog, c’est comme partout. Il y a les “laborieux”, les “artistes”, les “orfèvres”…et les égarés.
Le code pourri est an général pondu par un “artiste” qui code à l’intuite, qui ne peut pas se permettre de trop réfléchir sur les noms de variables pour ne pas perdre le fil de son inspiration; se promettant d’y revenir faire le ménage, et s’apercevant après coup que pour passer le balai, il va falloir bouger les meubles; qui malheureusement servent aussi à soutenir le plafond….
Après il y a les biclassés : les labortistes, les arfèvres, les égarieux…
amen :)
@Kontre. Mets y un dièse et une cléf de sol en entête et tu l’attaque en mi mineur.
Tin on dirait moi…
Le module de simplification de vie en HTTP, c’est requests, pas request.
Fixed.
Salut,
Y’a une page que je conseillais à tous quand je faisais un peu de python, c’était sur le blog de biologeek :
Bonnes pratiques et astuces Python
Bon, c’était du temps de python 2, mais je pense qu’il y a encore énormément de bonnes choses dedans. :)
C’est toujours le temps de Python 2. L’immense majorité du code Python est toujours en version 2, et le sera encore pour un bon bout de temps.
Faire
import thisdans l’interpréteur Python, personne ? :)Je me permet de signaler ici la plus belle initiative en matière d’API sur laquelle je sois tombé : docopt
Après avoir trouvé optparse et argparse lourds et chiants à utiliser, je dois dire que docopt m’a surpris par sa simplicité et son efficacité.
Mais je ne veux pas vous gacher la surprise : http://docopt.org/
(Sans compter que tout ça est très « Documentation driven coding », chose que j’apprécie beaucoup)
@foxmask
Merci pour vim-flake8, je ne connaissais pas il m’est très utile.
Je me permet de saluer ici la meilleur initiative qu’il m’ai été donnée de voir en matière d’API.
Ça s’appelle docopt et ça vient avantageusement remplacer les lourds, chiants et inamovibles optparse et argparse tout en incitant au « Documentation driven programming ». Je vous en dirais bien plus mais je préfère ne pas gacher la surprise.
Remarque :
ou bien c’est firefox qui plante en ne transmettant pas mon commentaire, ou bien c’est qu’il n’y a rien de prévu pour dire « Sisi on l’a reçu pas la peine de le renvoyer ! » auquel cas il pourrait être intéressant de le rajouter (tant pour l’utilisateur que pour vous d’ailleurs).
J’ai approuvé tes messages (sauf le doublon), je crois que c’est Askimet qui te fait pas confiance…
@cym13: wordpress met ton message en attente de modération, mais je n’ai jamais vraiment vérifié si il l’annonçait “votre commentaire est en attente de modération”. Par contre, j’aime le concept de docopt, mais je trouve clize vachement plus simple.
Ça fait 1 an que je me trimbale dans le module urllib2 de python 2.7 et je peux témoigner qu’il est vraiment à vomir. Il n’est absolument pas pythonique, très javatique avec énormément d’abstraction inutile et un énorme (et overkill) system de call chain qui permet de bien perdre le fil du flow d’exécution quand tu fais du pas à pas dedans avec PDB.