En ce moment un outil fait son petit buzz sur hackernews, mais je n’en avais pas parlé jusqu’ici car il n’était pas encore uploadé sur pypi. C’est chose faite :
pip install yapf |
Yapf est un reformateur de code, vous lui filez un fichier (ou un dossier à parcourir récursivement), et il reformate le code pour qu’il soit plus lisible, et plus proche du PEP8.
On en parle en ce moment car le code appartient à Google et que le projet est comparé à gofmt le formatteur intégré à la stack Goland dont les Golois nous ventent les mérites avec moult regards condescendant vers tous les autres langages depuis qu’ils l’ont.
Yapf est loin des features de gofmt pour le moment, mais c’est cool d’avoir un point de départ, car c’est vrai que ça manquait. Non pas que ça n’existait pas déjà, mais les tentatives précédentes n’avaient soulevé aucun enthousiasme, et donc pas beaucoup de contrib. Il a fallut, comme d’hab, qu’un concours de celui qui a la plus grosse motive tout ça à coup d’éGOs, si vous voyez ce que je veux dire. On a bien eu pip intégré à Python parce que les codeurs JS se foutaient de notre gueule avec npm installé par défaut.
Bref, pour le moment yapf s’occupe surtout des espaces et de l’indentation, mais il le fait bien.
Soit le programme suivant :
from __future__ import (unicode_literals, absolute_import, print_function, division) def yolo(a,b =None) : print ( "Ca fait mal aux yeux hein ?") a= 1 if a==b : return(b) if True and False:# c'est chiant n'est-il pas ? return "bob" WOLOLO = { [1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12] } OYOOYO = { [1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12] } # yapf: disable |
Un petit coup de :
yapf programme.py |
Et pouf, il vous sort :
from __future__ import (unicode_literals, absolute_import, print_function, division) def yolo(a, b=None): print("Ca fait mal aux yeux hein ?") a = 1 if a == b: return (b) if True and False: # c'est chiant n'est-il pas ? return "bob" WOLOLO = {[1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12]} OYOOYO = { [1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12] } # yapf: disable |
Yapf existe en ligne de commande, mais peut être utilisé comme une lib. En prime, avec -i, il peut modifier le fichier sur place au lieu de juste faire l’output dans le terminal.
J’espère vraiment qu’il va gagner en traction histoire de pouvoir mettre ça dans tous mes hook git et oublier une bonne fois pour toute les guéguerres de formatage, on a d’autres chattes à coder.
Mon cerveau a aussi remis les lettres dans l’ordre et s’est dit “marrant Un oiseau (piaf) qui fait le ménage”
Ça sera pratique parce-que sauter de vim a sublimetext parfois ça fout les nerfs en pelote quand bien même “tabstop 4″….
Sympa comme utilitaire,
Un collègue m’a indiqué aussi <a href=””https://github.com/SublimeLinter/SublimeLinter-pep8″ title=”SublimeLinter-pep8″>SublimeLinter-pep8 qui est un plugin de SublimeText et qui fait à la fois la détection des non-conformités avec PEP8 mais propose aussi de corriger le code pour nous…
SublimeLinter-pep8 nécessite le plugin SublimeLinter”…
Pour citer une “tentative précédente” il y a autopep8 (https://pypi.python.org/pypi/autopep8). Je n’ai pas comparé les résultats.
Non seulement l’outil est comparé à gofmt mais si j’ai bien compris il utilise la même lib sous-jacente.
Par contre l’indentation à 2 espaces par défaut, c’est un troll de google ?
Tin c’est cool ça !
J’étais en plein projet d’interface homme-machine, et mon prof me prend la tête pour pondre du pep8 mais j’ai la flemme ^^^^””
Et c’est là que j’reçois un mail newsletter de sam&max…
“tu veux du pep8? t’as qu’as taper : yapf jaimepalepep8.py ”
et hop… tout est bien qui finit bien, merci les gars =D !
perso j’ai jamais vraiment accroché avec l’imposition des coding rules par python, via pep8.
Je pige pas bien l’intérêt d’imposer la même coding rules à tous.
Par exemple dans mon cas, venant du C/C++ avec un typage fort à la compilation, j’ai cette habitude de préfixer mes variables avec leur type. Je sais qu’avec python on est sur du typage dynamique, et que la variable peut être à priori de n’importe quel type, tant qu’elle dispose des API attendues, ca passe grace au duck typing. N’empêche que j’aime bien que le nommage de la variable m’indique le type à priori attendu. Je vois pas au nom de quoi python “m’interdit” ça via pep8.
c’est grave docteur ?
Rassure-moi, tu travailles toujours tout seul ?
Non car en équipe, ou quand tu bosses sur un projet à plusieurs en général et sans coding style, je te dis pas le bordel. C’est une plaie de lire les autres et inversement. Et ça fait perdre du temps, beaucoup de temps.
Au nom du travail d’équipe. Tous les goûts sont dans la nature, et beaucoup de style se valent. On peut passer des années à en discuter et jamais se mettre d’accord. Le PEP8 tranche et dit “ca sera pas parfait, mais au moins on fera tous la même chose”.
C’est la raison pour laquelle il est si facile d’arriver dans un nouveau projet en Python. La plupart des gens respectent 80% du PEP8, et donc tu peux très vite lire et modifier un code étranger. En C++, tu va avoir des conventions différentes partout, et dès que tu vas arriver dans un nouveau projet, ta productivité va baisser aussi à cause de ça. Le pire, c’est quand tu travaille sur 2, 3 projets avec des conventions différentes. A chaque fois que tu switch, ton contexte mentale doit changer, et c’est tuant.
C’est donc un compromis qui fait passer l’individu après la collectivité.
@Knutknut
je me suis mal exprimé, je me fais pas mes propres coding rules, heureusement, je parlais des coding rules des projets auxquels j’ai participé, et qui ont en général cette règle là.
Sinon oui je suis bien conscient de l’intérêt d’avoir des règles de codage partagée entre les membres du projet
@sam
je me rends pas compte à quel point c’est utilisé pep8. Tu dis que les gens utilisent 80% de pep8, mais TOUS les projets sont en pep8 ?
Si c’est le cas pas de doute je vais bien devoir m’y coller – même si ça me fait quand même un peu chier… ;-)
D’autant plus que la PEP8 est une convention et que ton script python ne va pas s’arrêter de fonctionner parce que tu ne le respectes pas. C’est une référence qui a le mérite d’exister qui impose de bonnes pratiques. Je tombe régulièrement (je suis dans un contexte de calcul scientifique) sur des codes très mal formatés de vieux de la vieille ayant chacuns leurs habitudes. Résultat des courses, il faut parfois tout reprendre/tout recoder pour améliorer les routines.
@toub: l’immense majorité des codes qui sont utilisés. Il y a plein de petits projets qui ne le sont pas, mais dès que tu as une lib qui devient un peu utilisée, elle l’est. Si elle ne l’est pas, les premiers contributeurs vont généralement la reformater pour permettre de mieux travailler par la suite. Ca fait vraiment partie de l’adn de la communauté Python.
Mais la communauté est assez saine là dessus : pas de comportement formatnazi. Si quelques règles sont oubliées, c’est pas la mer à boire. L’important c’est de pouvoir scanner facilement le code de ses yeux leur d’une lecture rapide.
Un autre outil intéressant :
https://github.com/landscapeio/prospector
moi, pour mon premier commentaire et en n’oubliant pas remercier ce site et ses auteurs pour la qualité de leurs articles, je plussoie le sublime-linter-pep8 évoqué plus haut !
en effet, developpeur débutant non pro, si mon code est encore loin d’etre pythonic, qu’il fonctionne encore trop souvent grace a de subtils coup de chance, et bien au moins il est pep8 (hahum) et a force de corriger via le linter visuel et bien j’ai pris l’habitude de cette convention et naturellement je l’applique. (en revanche, tj du mal a anglifier)
Je ne sais pas si j’ai raté un truc, mais concrètement par rapport a autopep8, qu’apporte yapf?
À part l’enthousiasme (ou le fric de google selon comment on voit les choses), si j’ai bien compris la grosse différence c’est qu’autopep8 ne corrige que ce qui est flaggué par pep8, point final.
Au contraire yapf va restyler tout le code quoi qu’il arrive, donc quel que soit le style de départ tu arrives au même résultat.
Mais c’est étonnant quand même comme d’un coup tout le monde parle de yapf !