Il y a bien longtemps je vous avais parlé de 7 libs Python vraiment chouettes, puis quelques articles pour vous signaler des remplaçants, ici et là.
Comme je ne m’attends pas à ce que vous suiviez le blog article par article, voici une petit synthèse, la conclusion de l’évolution de ma boîte à outils Python.
D’abord, ce qui n’a pas changé
Ipdb, est toujours de la partie. Je m’essaye à pudb de temps à autre, mais vraiment pour casser l’habitude. Ipdb reste la référence pour tout debugger. C’est simple, c’est puissant, c’est fantastique.
path.py, inébranlable remplacement de os.path et shutil, malgré l’intégration de pathlib à python 3.4 qui est loin d’être aussi bon. J’ai même fait quelques contributions sur le projet, notamment l’écriture de fichier “inplace”.
requests, la fantastique lib HTTP, qui n’évolue plus beaucoup, car qui a besoin d’améliorer la perfection ? On regrettera l’absence de version asynchrone, bien que certains projets alternatifs, moins bons, s’y collent.
bottle, toujours pour bricoler des sites rapides. Mais de moins en moins, maintenant que django_quicky est bien rodé, si je sais que le site va déboucher sur un truc, c’est plus productif d’utiliser ce dernier.
peewee, surtout pour introduire les gens à la programmation avec base de données durant les formations. SQLAlchemy c’est bien trop dur, et l’ORM Django se ramène avec tout le framework. Mais pour mes besoins rapides, j’avoue que je tape de plus en plus dans Redis ou du flat file. C’est souvent du jetable de toute façon et je manipule itertools mieux que SQL ou toute couche ORM au dessus.
grin est toujours là. Parce que je ne me souviens jamais des millions de flags de grep pour obtenir ce que grin donne gratos, comme la coloration, le contexte, la récursivité et l’exclusion du dossier .git. Parce qu’il prend les regex Python en compte. Parce qu’il marche sous n’importe quelle plateforme supportée par Python de la même manière, y compris Windows, et s’installe avec un pip install grin --user sans avoir besoin des droits root.
Ce qui a changé
Adios dateutil, bonjour arrow. Ok, je triche un peu, car arrow utilise dateutil sous le capot, mais je n’en vois jamais la couleur. Arrow est plus simple, plus beau, plus productif, plus mieux. Les dates, telles que ça devrait être dans la lib standard.
Ensuite, au revoir clize, place à docopt pour parser toutes les lignes de commandes. Les fonctionnalités avancées de click ne m’ont pas convaincu de migrer, et docopt est tellement intuitif, tellement merveilleux dans son fonctionnement…
minibelt fait maintenant partie de tous mes fichiers requirements. Surtout pour son sorted set, son dmerge, ses get, attr et iget. Parfois pour chunk et windows. C’est tellement rageant de devoir recoder ces petites fonctions pour chaque projet.
pyped est de plus en plus utile chaque jour. Depuis l’article du blog, il a bien évolué et embarque un tas de goodies comme le spliting via options, l’auto filter ou encore le parsing JSON. Bref, je n’ai plus touché à sed depuis des mois.
pytest partout. Je ne touche plus au module unittest de la stdlib ni celui de Django. pytest est la réponse à tout et même plus, c’est 42 + 1, c’est la seule raison pour laquelle je fais encore des tests.
six. Pas parce que j’aime cette lib, mais parce que je me tape pas mal de conversion Python 2/3 en ce moment, et six est le socle sur lequel repose toutes mes migrations. Pourvue que je n’ai bientôt plus besoin de l’utiliser. Oui, oui, je sais, on doit migrer 0bin et tous les autres projets. Un jour.
Pas directement lié à Python, mais pour faire des UI au dessus de mes APIs en Python. jQuery est petit à petit en train d’être remplacé par angularjs que je commence à bien maitriser. Ça mériterait un paquet d’articles rien que pour le bestiau mais je vais m’en tenir au 180 drafts qu’on a déjà en stock :) Et puis jQuery a encore de beaux jours devant lui pour tous les sites qui ont besoin de ref, les sites legacy, les petits sites qui n’ont pas besoin d’un bazooka pour l’UI…
Un autre truc que j’utilise tous les jours, c’est la liste des cours du blog avec une recherche type “site:http://sametmax.com/cours-et-tutos/ mes mots clés” car le moteur de recherche de wordpress est à chier. Et franchement, je me félicite régulièrement du dump du blog parce qu’Internet est pas stable ici et la consultation hors ligne devient vite indispensable. Pour cette même raison, j’ai installé zeal avec la doc de python en local.
Ce qui est resté au placard
Je pensais que j’utiliserais beaucoup templite, mais en fait pas du tout. Comme minibelt contient mes fonctions favorites, batbelt, sa grande soeur, s’ennuie, surtout qu’elle n’est toujours pas compatible Python 3.
Plus de Beautiful soup. Je ne parse plus de HTML, il y a des APIs partout… Plus de Fabric. J’utilise docker et je déploie mes instances à la main (j’ai pas 500 serveurs à gérer).
J’ai aussi fait un long essai du shell fish, mais je ne suis pas convaincu et je vais retourner à ce bon vieux bash.
Je ne sais pas si vous connaissez grequests, fait par Kenneth Reitz également et qui grâce à gevent et requests permet de faire de l’asynchrone.
sur une debian wheezy, pour utiliser docker on est obligé d’en passer par la compil d’un kernel ; ca fait iech la teub. d’autant que docker dit supporter que la v8 …
pour shutil je pense pas que path.py permette de pondre des archives (comme make_archive()) non ?
Tu as pu tester Flask ? J’imagine que oui mais j’ai l’impression qu’il devient de plus en plus populaire, car simple à utiliser et ne réinvente pas la roue (KISS quoi).
Sinon j’aime beaucoup l’idée de billet recap, j’avais loupé pyped et je vais de ce pas le découvrir :)
@foxmask je te réponds car ton message m’a amusé :
– Docker est la techno hype du moment. Donc marche facilement sur OS X / Ubuntu / Fedora / Archlinux. Mais vu que Debian est plutôt conservateur, c’est clairement pas le public cible pour le moment. Utilises tu simplement l’OS adapté à ton usage ?
– le but de path.py est de rendre les manipulations de fichiers plus “humaine” (exemple de walktree). Mais shutil étant facile à utiliser, il y a moins d’intéret de l’abstraire. Mais rien ne t’empêche de faire un pull request sur Github ;)
@morgoth si t’as ri tant mieux :)
pour debian, oui c’est le bon usage et ca fait depuis 2000 que je m’en sers donc … remarque si j’étais timbré je pourrai mettre docker sur windows
pour shutil je sais bien que c’est simple mais si path.py pouvait abstraire shutil au poil, c’etait une question en l’air. pour le pr sur github c’est pas demain la veille ; chuis un noob en python hein.
Super article, j’consultais l’article des 7 libs python encore récemment.
Une idée d’article dans le même genre (même si t’as l’air d’avoir un max de draft), la boîte à technos web que t’utilises (ou pas d’ailleurs). Pas un article qui débouche sur un troll, juste pour avoir une vue d’ensemble pour les neophytes et mieux s’y retrouver.
Concernant django-quickly. Je vois qu’on peut renvoyer assez simplement du json, ça peut remplacer tastypie pour un usage basic à ton avis ?
Je te conseille le shell ZSH
http://fr.wikipedia.org/wiki/Z_Shell
Je m’intéresse de très près à toutes ces petits librairies qui peuvent faire gagner du temps, mais les recommanderiez-vous pour un usage professionnel sur un projet longue durée ?
@Krypted: je n’aime pas gevent pour 3 raisons :
– il faut compiler une extension C;
– le context switching est implicite, on ne sait pas où dans son code ça va trancher;
– ça monkey patch les libs internes, ce qui est cool pour la facilité d’utilisation, mais question propreté…
Après, je reconnais que ça marche et que c’est efficace.
@foxmask : non, et c’est à rajouter, mais on y retrouve les outils pour supprimer des dossiers récursivement notamment. Concernant docker, c’est clair que c’est un truc qui tourne que sur des serveurs récent. C’est toujours comme ça en info. D’ailleurs, docker ne tourne pas sous Mac ni Windows.
@Morgotth: comme je l’ai dis souvent, pour les petits sites, j’utilise bottle, pour les gros, django, du coup il reste pas de place pour flask. Mais oui je l’ai essayé. J’ai du mal avec le principe de l’objet request implicite passé via le thread context.
@heavy27z: http://sametmax.com/la-stack-techno-quon-utilise-pour-faire-un-site-web-et-pourquoi/
@Saïd: je l’utilise beaucoup pour ça. Pour les petites APIs, quand j’ai pas envie de sortir l’artillerie lourde (je suis plutôt django-rest-framework que tastipie par contre), je fais 2 / 3 vues à la main, et pouf. Pour j’avais pas été convaincu. Je vais retenter.
@Marc : je les utilisent toutes en tant que professionnel.
J’ai vu une version pour windows pourtant mais bon :-)
Il faut utilser une machine virtuelle linux :
http://docs.docker.com/installation/windows/
Bonjour, juste un petit détail qui pique. Au tout début de l’article : “je vous avez parlé”. À remplacer par “Je vous ai parlé”.
Merci pour cet article et les autres, toujours aussi intéressant.
Hello, merci du signalement. En fait serait plutôt “je vous avais parlé.
@Foxmax, en fait c’est utilisable sur Debian Wheezy.
Suffit de mettre le repo backports et tu te retrouves avec un kernel 3.14 suffisant pour Docker. Pas besoin de recompiler toi-même du coup.
@Jo : merci ! je testerai dès que possible.
J’aurai dû passer hier ca m’aurait eviter de passer l’apres midi à remettre debian apres avoir tenté l’install ubuntu en dual boot :)
Ça serait cool d’avoir un post sur votre workflow de développement de la création d’un projet avec les outils que vous utilisez jusqu’au déploiement.
J’ai fait quelques applications avec django.
Et je n’ai pas encore eu le courage d’un déployer une seule.
Il y a tellement de trucs à prendre en compte comme la sécurité, les certificats ssl, les mises à jour, le versionning et j’en passe.
Il y a les services cloud comme heroku, mais c’est hyper chiant à configurer ! Il faut changer les settings de son applications (config serveur, base de données).
On entend parler de plus en plus de docker, mais je ne vois pas en quoi c’est intéressant pour un web developer.
On a souvent un environnement différent de celui d’un serveur en prod, car on utilise des outils qui n’ont pas lieux d’être sur ce type de serveur comme git, ruby (compass, sass).
Ou alors il faut créer deux docker ?
Bref un post à ce sujet serait fort intéressant.
@inceptiondock : quel type de projet ? Parce que le déploiement est différent selon la nature du projet.
Ça il faudra toujours le faire. Tu mets pas en prod tes configs de dev.
http://sametmax.com/le-deploiement-par-conteneurs-avec-docker/
TL;DR: tu fais ton déploiement une seule fois, et tu ship juste le conteneur sur chaque machine de prod.
C’est souvent le cas, on ne devrait pas, mais ça nous arrive souvent.
Git, compass et sass ont parfaitement leur place en prod.
Une excellente appli pour utiliser de la doc offline : http://kapeli.com/dash
Votre django-quicky m’évoque importd : http://pythonhosted.org/importd/.
Django-quicky est fortement inspiré de importd. Mais importd ne peut pas être mélangé à du code django normal, ce qui est limite énormément.
Han, merci !
Shameless plug pour ma version, qui ne souffre pas de tous les bugs unicode de path.py, pathlib, … : rpaths. Parce que, soyons sérieux, c’est le rôle de la lib de gérer ces conneries d’encodage.
J’aurais vraiment préféré que tu contribue à la gestion de l’unicode de path.py plutôt que de continuer sur pathlib, surtout que path.py a beaucoup plus de fonctionalités. Là ça divise les efforts.