Les bonnes pratiques pour faire du Python

L’article est intéressant car il parle vraiment de plein de choses. Je ne suis pas forcément d’accord avec tout, mais c’est une bonne synthèse je trouve.

1 « J'aime »

Merci pour ce partage.
Par curiosité : avec quoi n’es-tu pas d’accord, et pourquoi ?

Je saute dans le wagon sans avoir payé mon ticket, déso.

Use a tool like mise or pyenv to install Python on your development systems

Pas d’accord, compiler Python c’est ./configure; make; make altinstall, le seul truc chiant c’est d’avoir toutes les bonnes dépendances, chose que pyenv ne résoud même pas. Par contre pyenv amène pléthore de bidouilleries innutiles qui me sortent par les yeux. Je veux un outil qui fasse une chose et qui le fasse bien, pas “ah et attends j’te drop 3 symlinks là et un fichier de conf là et un hook dans ton bashrc et …” wow stop.

A la limite pour ceux qui veulent vraiment re-compiler des versions de Python tous les matins et qui veulent plus court que ./configure; make; make altinstall (comme moi) j’ai fait : https://git.afpy.org/mdk/compile-python qui me semble beaucoup plus sain que pyenv (mais je suis biaisé c’est moi qui l’ai fait).

Use The Most Recent Version of Python That You Can

Yeah, +1.

Avoid using Python 2

Yeah +1000.

Use pipx To Run Developer Applications

OK oui pourquoi pas.

python3 -m pip install --user pipx

ahh bah non ça c’est débile, si j’utilise pipx c’est pas pour me retrouver avec une install hors venv. Ça ne passe même pas sur des OS récents :

python3 -m pip install --user pipx
error: externally-managed-environment

qui 3 lignes plus loin conseille lui-même d’installer pipx :

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

donc non, surtout pas pip install --user pipx mais sudo apt install pipx.

Avoid Using Poetry

+1, ma raison : j’utilise des outils qui ne font qu’une seule chose mais qui le font bien.

Use a pyproject.toml File

+1

Create a Directory Structure That Uses the src Layout

-0 : ça ne fait pas consensus (il existe plus de projets Python sans src/ qu’avec). Je n’utilise pas de dossier src pour plusieurs raisons :

  • pouvoir lancer python -m pytest avant d’avoir pris le temps de packager (wow l’argument, lol)
  • juste pouvoir tester un truc dans un REPL sans se casser la tête: lancer Python, importer le truc, jouer avec.
  • dans mon dossier src il n’y aurait qu’un seul dossier du nom du paquet, ça me semble bien inutile, un dossier qui contient un dossier.

Use Virtual Environments for Development

Évidement.

Use Requirements Files to Install Packages Into Environments

Oui.

Format Your Code

+1 sauf pour ceux qui sont tous seuls sur leur projet ET qui sont capable de faire mieux que Black. Il faut être un artiste, mais j’en connais (Entwanne par exemple).

Use a Code Linter

+1 mais flake8 is currently the most popular linter for Python j’aurais plutôt dit pylint, dommage qu’il ne parle pas de pylint, ça poutre pylint.

Test with pytest

+1000, il aurait parlé de nose j’aurais fermé l’onglet.

Package Your Applications

+1

Use Type Hinting

Ouai alors euh, on est dans un pays libre hin, chacun fait comme il veut.

Format Strings with f-strings

+0, j’adore les f-strings, mais il n’y a pas que ça, l’internationalisation c’est important aussi.

Use Datetime Objects with Time Zones

+1

Use enum or Named Tuples for Immutable Sets of Key-Value Pairs

+0

Create Data Classes for Custom Data Objects

+1 mais attends c’est quoi des “Data objects” ? Ça n’a aucun sens, tous les objets sont des “data objects”, dit autrement, il ne devrait pas exister d’objet dont le seul but ne soit pas de contenir de la donnée… (sauf une sentinelle ?).

Use collections.abc for Custom Collection Types

-0, on est pas en C++ non plus.

Use breakpoint() for Debugging

+1

Use Logging for Diagnostic Messages, Rather Than print()

+1

Use The TOML Format for Configuration

+100

Only Use async Where It Makes Sense

Ouai enfin c’est très généralisable… “Only use regex when it makes sense”, “Only use the network when it makes sense”, “Only use antibiotics when it makes sense”, …

Handle Command-line Input with argparse

+1

Use pathlib for File and Directory Paths

+1

Use os.scandir() Instead of os.listdir()

Bah non, Pathlib.walk, faut être cohérent avec l’item précédent, c’est généré par une IA ou quoi ?

Run External Commands with subprocess

+1, c’est plus rapide qu’avec M-x butterfly-execve.

Dans la description de ce paragraphe on trouve rather than shell backquoting, ça n’a jamais existé en Python, cet article est rédigé par une IA j’aime pas ça…

Use httpx for Web Clients

+0, pas d’avis, j’ai essayé mais quand c’était en beta donc mon avis ne compte pas, je dois reessayer.

6 « J'aime »

Bonjour,

Merci pour ce document. Il me semble toutefois qu’il manque deux éléments essentiels:

  • la prise en main rapide;
  • la documentation du code.

Une prise en main rapide destinée au débutant en guise d’introduction permettrait de faire une bonne transition avec la suite de l’article qui semble dédié à un public plus averti. En quoi une pratique est bonne ? Utiliser la version déjà installée sur sa distribution est une bonne pratique dans le sens ou elle permet au débutant de démarrer rapidement sans s’affronter à d’autres difficultés tel que par exemple une connaissance insuffisante des principales commandes de son de son système d’exploitation. Il semble bien que cet article est oublié de préciser à quel public il s’adresse. Les “bonnes pratiques” en se parant du qualificatif “modernes” se doivent de ne pas négliger l’aspect pédagogique trop souvent sacrifié. Ce texte mériterait d’être développé pour être accessible à toute personne ne connaissant pas Python et qui envisagerait d’y goûter rapidement et facilement. Contrairement a une idée répandue, une bonne pratique ne s’adresse pas qu’aux personnes expérimentées car il est important que l’apprenant l’adopte au plus vite.

En ce qui concerne la documentation de code, Python offre de bonnes possibilités qui mériteraient d’être mises en avant. Un code lisible et bien documenté est une bonne pratique garantissant une maintenabilité, une meilleure pérennité et réutilisabilité.

Ces éléments fournis ne remettent pas en cause le fond de l’article mais visent à encourager la valorisation de son contenu en donnant quelques pistes sur la forme. Bien évidemment si des éléments erronés sont présents, ils se doivent d’être corrigés, adaptés ou supprimés.

3 « J'aime »

À vouloir donner des règles universelles je trouve que ce document se foire dans le dogmatisme.

Sinon je pense avoir une vision assez proche de mdk donc il va y avoir de la redite, mais :

Avoid Using the Python Installation in Your Operating System

Pas d’accord : un OS est fait pour ça, mettre à disposition des paquets partagés.
On ne veut pas que chaque projet embarque sa propre version de Python, on veut plutôt un système cohérent dans son ensemble.

Install Python With Tools That Support Multiple Versions

Pas besoin d’outils particuliers pour ça.
Si j’ai différents Python installés sur mon système (une version stable et une beta par exemple) je peux créer des venv liés à ces différents Python.

./path/to/python -m venv env

Format Your Code

Unpopular opinion: chacun son style, pas d’uniformisation à l’extrême.
Et la dimension artistique dans tout ça ‽

Il y aura dans tous les cas toujours des différences (dans les manières de nommer, de structurer les boucles et conditions) : je suis pour des règles de lint partagées (imposer une même indentation, pas d’espaces en fin de ligne, placement des espaces autour des opérateurs) pour éviter les abus, mais pas de reformater les codes pour imposer tel retour à la ligne après un argument ou autre.

Test with pytest

Pytest :heart:

Package Your Projects

+1000 mais pas seulement les projets partagés.
Un paquet n’a pas besoin d’être publié, mais déjà lui donner la forme d’un paquet simplifie les choses (gestion des dépendances, imports relatifs, points d’entrée) dans un environnement local.

Use f-strings instead of % formatting, str.format() or str.Template().

Les f-strings et str.format n’ont pas forcément les mêmes usages.
Il reste utile de pouvoir définir un template de chaîne et d’utiliser plusieurs fois format dessus avec des arguments différents.

To achieve concurrency with Python, you must run multiple Python processes.

???
Il veut parler de parallélisme uniquement je pense.

You must still ensure that asynchronous functions never call any synchronous function.

Tout dépend. On ne va pas interdire l’utilisation du module math dans les fonctions async.

Create a Directory Structure That Uses the src Layout

Question de goût. Flat is better than nested, tout ça.
Mais je comprends l’idée de s’assurer via l’indirection src qu’on n’importe pas un répertoire local mais bien le paquet installé.

Use Requirements Files to Install Packages Into Environments

Oui, c’est même le bon cas d’usage des fichiers requirements (Do not use requirements.txt • Tribune • Zeste de Savoir).


Les antibiotiques, c’est pas automasync !

1 « J'aime »

Totalement d’accord dit l’auteur d’un outil particulier pour ça.

Je dirais même plus, avec $HOME/.local/bin dans son PATH et en utilisant make altinstall (ce que fait mon outil particulier pour ça évidement, mais à la main ça prend 3 commandes en comptant le wget), les commandes suivantes sont sans surprises :

$ python3.7 -m venv .venv-legacy
$ python3.10 -m venv .venv-prod
$ python3.13 -m venv .venv-futur

Et tox trouve évidemment aussi ces versions de Python par leur nom, ça juste marche.

Ouais, j’ai généralement très peu de cas d’usage où je veux utiliser une version de Python différente de celle par défaut.

Quand ça arrive, soit c’est pour tester un cas particulier sur une version antérieure/postérieure qui est alors installée via le gestionnaire de paquets du système et que je référence par sa version précise (donc python3.11 -m venv par exemple ici).

Soit une version pas encore packagée sur mon système et je n’ai pas trop le réflexe d’utiliser des outils particuliers pour ça, j’ai toujours un clone du dépôt Python qui traîne dans un coin : je pull le tag / la branche qui m’intéresse, je compile et j’utilise mon venv.