Ça fait longtemps que je souhaite publier annuellement mes outils python préférés. C’est pratique pour plein de gens et ça permet de voir l’évolution de ceux-ci au fil du temps et des projets sur lesquels je contribue.
Voici donc la première édition de cette liste.
Outils de développement
poetry
Poetry est mon gestionnaire de paquet de choix.
ruff
Ruff est un « linter » et un outil de formatage de code. Il roule à la vitesse de l’éclair et contient une quantité impressionnante de fonctionnalités qu’on retrouve dans des plugins flake8. Je ne connais personne qui, après avoir essayé ruff, a préféré garder un autre « linter ».
Pour moi, en 2023, il a remplacé flake8 et de nombreux plugins flake8. Pour ce qui est de leur intégration de black, elle n’est pas encore à point, selon moi, alors j’attends avant de l’utiliser.
Ma configuration ruff du moment:
select = ["B", "D", "E", "F", "I", "T20", "W", "N", "YTT", "ASYNC", "S", "A", "C4", "DTZ", "T10", "PIE", "PT", "RSE", "SLF", "SIM", "TCH", "PTH", "PGH", "PLC", "RUF", "RET"]
# D1 - Pas besoin de docstrings partout, tout le temps.
# D401 - Pas besoin de docstrings impératives. (Ça m'irait, mais j'ai des collègues en désaccord.)
# D413 - Je ne comprends pas pourquoi avoir des lignes blanches à la fin des docstrings est important.
# PTH123 - Je suis ok avec le "open" normal, sans passer par pathlib.
# RUF001 A des faux positifs, surtour en français. "L'individu" -> "Lindividu"
ignore = ["D1", "D401", "D413", "PTH123", "RUF001"]
# F401 - Enlève les imports non utilisés. Très achalant quand l'éditeur de texte roule le "--fix" à chaque sauvegarde.
# F841 - Enlève les variables non utilisées. Même excuse que pour F401.
# PIE804 - Remplacer les kwargs avec des arguments normaux. Achalant quand on travaille avec pydantic et qu'on souhaite tester l'interface kwargs.
unfixable = ["F401", "F841", "PIE804"]
pydocstyle = {convention = "google"}
black
Un formatteur de code avec très peu de paramètres, ce qui évite les discussions et débats au sein de l’équipe.
mypy
Un « static type checker » pour python. C’est difficile à croire qu’il fut un temps où on codait des applications python complexes sans un outil du genre. C’est aujourd’hui un essentiel. Pourquoi mypy vs Pyre ou pyright? Je n’ai pas de bonne raison. J’ai commencé avec mypy, ça a répondu à mes besoins et je n’ai jamais essayé ou comparé les alternatives.
pytest
pytest est une librairie pour tester des applications python. Oui, python vient avec le module unittest, mais pytest s’est illustré par ses fonctionnalités avancées et ses plugins. Je l’utilise maintenant depuis des années. Je n’ai pas entendu parler d’un rival de taille pour le remplacer et je n’en ressens pas le besoin non plus.
hypothesis
C’est un peu un mensonge de ma part que de prétendre que hypothesis est dans mon coffre à outils python. C’est un excellent outil, une manière de rendre les tests beaucoup plus robustes, mais je suis loin de m’en servir autant que je devrais. Je ne le maitrise simplement pas assez pour l’utiliser efficacement. C’est pourquoi je le mets sur la liste malgré tout.
bandit
Bandit est un outil qui scanne statiquement le code et relève des sources potentielles de problèmes de sécurité. Il est techniquement intégré dans ruff, mais je ne suis pas certain encore s’il le remplace totalement ou si les mises à jour de bandit se rendent assez rapidement dans ruff ou non. Dans le doute, je garde les deux. Comme on parle de sécurité, je préfère ne pas courir le risque.
Outils de production
structlog
Structlog est une librairie de journalisation. Je m’en sers principalement pour faire, comme son nom l’indique, de la journalisation structurée (structured logging). Une fois configuré correctement, en local il imprime dans la console avec des couleurs. Dans le nuage, je le configure pour envoyer les « logs » en JSON, ce qui est très pratique pour chercher ensuite avec des outils comme ElasticSearch ou AWS Log Insights.
pydantic et pydantic-settings
Une bonne pratique de développement est de valider toutes les données entrantes. Pydantic permet de le faire à différents niveaux et pydantic-settings le fait pour le chargement de la configuration. Celui-ci supporte des fichiers de configurations, .ini, .env, des variables d’environnement et plus encore, ce qui le rend très flexible.
Sur le balado Talk Python To Me, j’ai récemment entendu parler de msgspec, qui est beaucoup plus rapide encore que pydantic. (lien vers l’épisode) Je ne l’ai ni essayé ni comparé pour voir s’il peut vraiment le remplacer ou si c’est fait pour d’autres cas d’utilisation. À suivre.
fastapi
FastAPI est un cadre d’application web. Il supporte asyncio, effectue de la validation des données entrantes avec pydantic et ce sert de ces mêmes modèles de validation pour produire une spécification OpenAPI. Pour moi, il a remplacé flask.
sentry-sdk
Cet item trahit quel gestionnaire d’erreurs j’utilise le plus. Il est sur la liste de cette année, mais risque de disparaître d’ici l’année prochaine. Je travaille beaucoup avec les AWS Lambdas et sentry-sdk prend un temps fou à s’initialiser: 1 seconde pour certaines de nos fonctions en production. sentry-sdk détecte automatiquement les librairies utilisées, alors s’il découvre FastAPI dans l’environnement, même s’il n’est pas utilisé, il prend un 200ms de plus à s’initialiser. Si vous êtes familier avec la concept de « cold start », vous comprendrez que c’est inacceptable pour servir des réponses rapidement dans un API.
sqlalchemy et alembic
sqlalchemy est une librairie d’outils pour interagir avec des bases de données. Elle permet aussi de « mapper » des modèles python aux tables de la base de données.
Alembic permet de créer de versions de la base de données. On s’en sert ensuite pour effectuer des mises à jour ou revenir en arrière si ça ne se passe pas comme prévu.
Si vous avez des outils incontournables à me suggérer, vous pouvez les indiquer dans les commentaires.