Wie funktionieren Context Manager, und wann hast du selbst einen geschrieben?

Ein Context Manager ist jedes Objekt mit dunder enter und dunder exit. Das with-Statement ruft enter auf, bindet den Rückgabewert an das as-Ziel und garantiert, dass exit danach läuft, auch wenn der Body eine Exception wirft. Exit bekommt die Exception-Details und kann die Exception unterdrücken, indem es True zurückgibt. Der Decorator contextlib.contextmanager lässt dich dasselbe als Generator mit einem einzigen yield schreiben.

Das Protokoll besteht aus zwei Methoden. Enter macht das Setup und gibt zurück, was nach dem as-Schlüsselwort gebunden werden soll, und exit macht den Abbau. Wichtig ist, dass exit läuft, egal ob der Block sauber durchgelaufen oder explodiert ist, und es bekommt Exception-Typ, Wert und Traceback, um zu entscheiden, was zu tun ist. True aus exit zurückzugeben schluckt die Exception, was ich sparsam nutze, weil es Fehler versteckt. Die meisten, die ich schreibe, nutzen contextlib.contextmanager, wo der Code vor dem yield das Setup ist, der Code danach der Abbau, und ich wickle das yield in try finally, damit das Aufräumen auch im Fehlerfall passiert. Bei einem Fintech habe ich einen für Datenbanktransaktionen gebaut, der zusätzlich eine Request-ID in den Logging-Kontext gestempelt hat, sodass jede Query im Block nachverfolgbar war und die ID beim Rausgehen gelöscht wurde. Davor haben wir das von Hand gesetzt und gelöscht, und ein frühes return in einem Handler hat die ID in den nächsten Request auf demselben Worker geleakt.