Geschichte der Frage
Bevor Python 2.5 die with-Anweisung über PEP 343 einführte, erforderte das Ressourcenmanagement explizite try/finally-Blöcke, die über Codebasen verteilt waren. Obwohl dies funktional war, war dieses Muster für einfache Szenarien zum Erwerb und zur Freigabe von Ressourcen umständlich und fehleranfällig. Das Modul contextlib wurde eingeführt, um diesen Boilerplate-Code zu reduzieren, indem es Entwicklern erlaubte, Kontextmanager als Generatorfunktionen zu schreiben und den @contextmanager-Dekorator zu verwenden, um sequenziell aussehende Generatoren in Objekte zu transformieren, die das Kontextmanagementprotokoll erfüllen.
Das Problem
Eine Generatorfunktion implementiert nativ das Iteratorprotokoll (__iter__, __next__), nicht das Kontextmanagerprotokoll (__enter__, __exit__). Die grundlegende Herausforderung besteht darin, diese unterschiedlichen Protokolle zu überbrücken: Beim Eintritt in einen with-Block muss der Setup-Code vor dem yield ausgeführt werden; beim Verlassen muss der Cleanup-Code nach dem yield ausgeführt werden, unabhängig von Ausnahmen. Darüber hinaus müssen Ausnahmen, die im with-Block ausgelöst werden, genau an dem Punkt, an dem das yield ausgesetzt ist, wieder in den Generator injiziert werden, damit die eigene Ausnahmebehandlungslogik des Generators die Aufräumoperationen ausführen kann.
Die Lösung
Der Dekorator umschließt die Generatorfunktion in einer GeneratorContextManager-Klasse (in modernem CPython in C implementiert). Jede Ausführung erzeugt einen frischen Generatoriterator. Die Methode __enter__ ruft next() auf diesem Iterator auf, führt die Funktion bis zur yield-Anweisung aus und gibt den zurückgegebenen Wert zurück, um an die as-Variable gebunden zu werden. Die Methode __exit__ erhält Einzelheiten zu Ausnahmen; wenn keine Ausnahme aufgetreten ist, wird next() erneut aufgerufen, um den Generator fortzusetzen und zu erschöpfen. Wenn eine Ausnahme aufgetreten ist, ruft sie die throw()-Methode des Generators auf und injiziert die Ausnahme am ausgesetzten yield-Punkt. Dies ermöglicht es, dass die except- oder finally-Blöcke des Generators die Aufräumarbeiten übernehmen. Wenn throw() normal zurückkehrt (Ausnahme erfasst), gibt __exit__ True zurück, um die Ausnahme zu unterdrücken; andernfalls propagiert sie.
from contextlib import contextmanager @contextmanager def managed_connection(): conn = create_connection() try: print("Verbindung hergestellt") yield conn except NetworkError: conn.rollback() raise finally: conn.close() print("Verbindung geschlossen") with managed_connection() as c: c.query("SELECT * FROM data")
Problembeschreibung: Ein Hochdurchsatz-Datenverarbeitungsdienst musste temporäre Spill-Dateien verwalten, wenn die In-Memory-Puffer die Grenzen überschritten. Die alte Implementierung duplizierte die Logik zum Erstellen und Löschen von Dateien in 12 verschiedenen Verarbeitungsmodulen, was zu Leckagen von Dateideskriptoren unter Randbedingungen führte und die Wartung komplizierte.
In Betracht gezogene Lösungen:
Manuelle try/finally-Blöcke waren der ursprüngliche Ansatz. Jeder Nutzungspunkt umhüllte Dateioperationen in expliziten try/finally, um sicherzustellen, dass os.unlink() aufgerufen wurde. Dies bot explizite Kontrollflusslogik ohne Abstraktionsüberhead, stellte sich jedoch als umständlich mit acht Zeilen pro Nutzungspunkt und sehr fehleranfällig heraus. Entwickler platzierten gelegentlich die Aufräumlogik im falschen finally-Block, und das konsistente Modifizieren von Verhalten über alle Module hinweg war mühsam, als Protokollierungsanforderungen hinzukamen.
Ein klassischer Kontextmanager wurde als wiederverwendbare Alternative erwogen. Eine TempSpillFile-Klasse würde __enter__ implementieren, um die Datei zu erstellen, und __exit__, um sie zu löschen. Obwohl wiederverwendbar und dem Standardprotokoll folgend, trennte die Klassendefinition visuell die Einrichtung von der Aufräumung über viele Zeilen, was die Lesbarkeit beeinträchtigte. Sie benötigte auch fünfzehn Zeilen Boilerplate für das, was konzeptionell ein einfacher Ressourcenlebenszyklus war, und verwischte die eigentliche Logik.
Der Generatoransatz mit @contextmanager war die endgültige Option. Eine temp_spill_file()-Generatorfunktion würde die Datei erstellen, sie zurückgeben und try/finally für das Löschen verwenden. Dies minimierte die Code-Duplikation und hielt Einrichtung und Aufräumung im Quellcode nahe beieinander und nutzte die vertraute Syntax der Ausnahmebehandlung. Es gab jedoch eine Einschränkung auf die Einmalverwendung, und der yield-Aussetzungspunkt könnte Entwickler verwirren, die eine synchrone Ausführung erwarteten.
Gewählte Lösung und Ergebnis: Der @contextmanager-Ansatz wurde gewählt, da er die Code-Duplikation minimierte und gleichzeitig die Klarheit während der Codeüberprüfungen maximierte. Die Nähe von Erwerbs- und Freigabelogik machte den Ressourcenlebenszyklus sofort offensichtlich. Das Refactoring reduzierte den Code für das Ressourcenmanagement von sechsundneunzig Zeilen auf zwölf Zeilen in der gesamten Codebasis. Statische Analysen bestätigten null Dateideskriptorlecks während des nachfolgenden Quartals der Produktionsnutzung.
Wie geht GeneratorContextManager mit Ausnahmen um, die während der Setup-Phase (vor dem yield) und der Cleanup-Phase (nach dem yield) auftreten?
Wenn eine Ausnahme vor dem yield im Generator auftritt, wird der Generator nie ausgesetzt; __enter__ propagiert diese Ausnahme sofort und __exit__ wird nie aufgerufen. Wenn eine Ausnahme innerhalb des with-Blocks (nach yield) auftritt, wird der Generator ausgesetzt. __exit__ ruft dann generator.throw(exc_type, exc_val, exc_tb) auf, was den Generator an der yield-Zeile mit der aktiven Ausnahme wiederaufnimmt. Dies ermöglicht es, dass die eigenen except- oder finally-Blöcke des Generators ausgeführt werden. Kandidaten übersehen oft, dass throw() tatsächlich die Ausführung wieder aufnimmt und dass die Ausnahme als aufgetreten betrachtet wird an dem yield-Ausdruck aus der Perspektive des Generators.
Warum erzwingt ein contextmanager-dekorierter Generator einen einzigen yield-Punkt, und welche spezifische Ausnahme tritt auf, wenn diese Einschränkung verletzt wird?
Das Kontextmanagerprotokoll geht von einem einzigen Eintritt und Austritt aus. Wenn der Generator ein zweites Mal yieldet – entweder weil __exit__ next() aufruft (keine Ausnahme) und der Generator erneut yieldet, anstatt zurückzugeben, oder weil throw() aufgerufen wird und der Generator die Ausnahme behandelt und dann erneut yieldet – tritt ein RuntimeError mit der Meldung "Generator hat nicht gestoppt" auf. Dies geschieht, weil die Zustandsmaschine erwartet, dass der Generator nach dem Aufräumen erschöpft ist. Kandidaten verwechseln dies häufig mit der standardmäßigen Iteration, bei der mehrere yields gültig sind, ohne zu erkennen, dass das yield als eine Aussetzungs-/Fortsetzungsgrenze für den Kontext fungiert, nicht als eine Werterzeugungssequenz.
Unter welchen Umständen unterdrückt die Methode __exit__ eines GeneratorContextManager eine Ausnahme, die im with-Block ausgelöst wird, und wie interagiert dies mit der Ausnahmebehandlung des Generators?
__exit__ unterdrückt die Ausnahme (gibt True zurück) nur, wenn die injizierte Ausnahme über throw() innerhalb des Generators erfasst wird und der Generator sein Ende erreicht (wirft StopIteration), ohne die Ausnahme erneut zu werfen oder eine neue zu erzeugen. Wenn der Generator die Ausnahme erfasst und es dem throw()-Aufruf erlaubt, normal zurückzukehren, interpretiert __exit__ dies als erfolgreiche Behandlung und gibt True zurück. Wenn der Generator die Ausnahme nicht erfasst, propagiert throw() sie nach außen, und __exit__ gibt None (falsch) zurück, wodurch die Ausnahme propagiert wird. Kandidaten übersehen oft, dass allein das Vorhandensein eines try/except innerhalb des Generators nicht ausreicht; die Ausnahme muss speziell vom throw()-Aufruf erfasst werden und nicht erneut geworfen werden, und dass eine explizite return-Anweisung oder ein Auslaufen am Ende nach dem Erfassen erforderlich ist, um die Unterdrückung zu erreichen.