Comment fonctionnent les gestionnaires de contexte, et quand en avez-vous écrit un vous-même ?

Un gestionnaire de contexte est tout objet doté de dunder enter et dunder exit. L'instruction with appelle enter, lie sa valeur de retour à la cible du as, et garantit que exit s'exécute ensuite même si le corps lève une exception. Exit reçoit les détails de l'exception et peut la supprimer en renvoyant True. Le décorateur contextlib.contextmanager permet d'écrire la même chose sous forme de générateur avec un seul yield.

Le protocole tient en deux méthodes. Enter fait l'initialisation et renvoie ce que vous voulez lier après le mot-clé as, et exit fait le nettoyage. L'important, c'est que exit s'exécute que le bloc se soit terminé proprement ou qu'il ait explosé, et qu'il reçoit le type, la valeur et la traceback de l'exception, donc il peut décider quoi en faire. Renvoyer True depuis exit avale l'exception, ce que j'utilise avec parcimonie parce que cela masque des erreurs. La plupart de ceux que j'écris passent par contextlib.contextmanager, où le code avant le yield est l'initialisation, celui d'après le nettoyage, et j'entoure le yield d'un try finally pour que le nettoyage ait bien lieu en cas d'erreur. J'en ai construit un dans une fintech pour les transactions de base de données, qui posait aussi un identifiant de requête dans le contexte de logs, de sorte que chaque requête SQL du bloc était traçable et que l'identifiant était effacé à la sortie. Avant cela nous le posions et l'effacions à la main, et un return anticipé dans un handler faisait fuiter l'identifiant sur la requête suivante servie par le même worker.