Verwendungssyntax für benutzerdefinierte Anweisungen

Die vorgeschlagene Syntax ist einfach

with EXPR1 [as VAR1]:
    BLOCK1

Semantik für benutzerdefinierte Anweisungen

the_stmt = EXPR1
stmt_enter = getattr(the_stmt, "__enter__", None)
stmt_exit = getattr(the_stmt, "__exit__", None)
if stmt_enter is None or stmt_exit is None:
    raise TypeError("Statement template required")

VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
exc = (None, None, None)
try:
    try:
        BLOCK1
    except:
        exc = sys.exc_info()
        raise
finally:
    stmt_exit(*exc)

Abgesehen von VAR1 werden keine der oben gezeigten lokalen Variablen vom Benutzercode aus sichtbar sein. Wie die Iterationsvariable in einer for-Schleife ist VAR1 sowohl in BLOCK1 als auch im Code nach der benutzerdefinierten Anweisung sichtbar.

Beachten Sie, dass das Statement-Template nur auf Ausnahmen reagieren, sie aber nicht unterdrücken kann. Siehe Abgelehnte Optionen für eine Erklärung, warum.

Statement-Template-Protokoll: __enter__

Die __enter__()-Methode nimmt keine Argumente entgegen, und wenn sie eine Ausnahme auslöst, wird BLOCK1 nie ausgeführt. Wenn dies geschieht, wird die __exit__()-Methode nicht aufgerufen. Der von dieser Methode zurückgegebene Wert wird VAR1 zugewiesen, wenn die as-Klausel verwendet wird. Objekte, die keinen anderen Wert zurückgeben sollen, sollten im Allgemeinen self anstelle von None zurückgeben, um die Erstellung "in-place" in der with-Anweisung zu ermöglichen.

Statement-Templates sollten diese Methode verwenden, um die Bedingungen einzurichten, die während der Ausführung der Anweisung bestehen sollen (z. B. Erwerb eines Synchronisationsschlosses).

Statement-Templates, die nicht immer verwendbar sind (z. B. geschlossene Dateiobjekte), sollten eine RuntimeError auslösen, wenn versucht wird, __enter__() aufzurufen, wenn das Template nicht in einem gültigen Zustand ist.

Statement-Template-Protokoll: __exit__

Die __exit__()-Methode akzeptiert drei Argumente, die den drei "Argumenten" der raise-Anweisung entsprechen: Typ, Wert und Traceback. Alle Argumente werden immer übergeben und auf None gesetzt, wenn keine Ausnahme aufgetreten ist. Diese Methode wird genau einmal von der with-Anweisungsmaschinerie aufgerufen, wenn die __enter__()-Methode erfolgreich abgeschlossen wird.

Statement-Templates führen ihre Ausnahmebehandlung in dieser Methode durch. Wenn das erste Argument None ist, deutet dies auf eine nicht-ausnahmebedingte Beendigung von BLOCK1 hin – die Ausführung hat entweder das Ende des Blocks erreicht, oder eine vorzeitige Beendigung wurde mit einer return, break oder continue-Anweisung erzwungen. Andernfalls spiegeln die drei Argumente die Ausnahme wider, die BLOCK1 beendet hat.

Alle von der __exit__()-Methode ausgelösten Ausnahmen werden an den Scope weitergegeben, der die with-Anweisung enthält. Wenn der Benutzercode in BLOCK1 ebenfalls eine Ausnahme ausgelöst hat, würde diese Ausnahme verloren gehen und durch die von der __exit__()-Methode ausgelöste ersetzt werden.

Faktorisierung beliebiger Ausnahmebehandlung

Betrachten Sie die folgende Anordnung der Ausnahmebehandlung

SETUP_BLOCK
try:
    try:
        TRY_BLOCK
    except exc_type1, exc:
        EXCEPT_BLOCK1
    except exc_type2, exc:
        EXCEPT_BLOCK2
    except:
        EXCEPT_BLOCK3
    else:
        ELSE_BLOCK
finally:
    FINALLY_BLOCK

Dies kann grob wie folgt in ein Statement-Template übersetzt werden

class my_template(object):

    def __init__(self, *args):
        # Any required arguments (e.g. a file name)
        # get stored in member variables
        # The various BLOCK's will need updating to reflect
        # that.

    def __enter__(self):
        SETUP_BLOCK

    def __exit__(self, exc_type, value, traceback):
        try:
            try:
                if exc_type is not None:
                    raise exc_type, value, traceback
            except exc_type1, exc:
                EXCEPT_BLOCK1
            except exc_type2, exc:
                EXCEPT_BLOCK2
            except:
                EXCEPT_BLOCK3
            else:
                ELSE_BLOCK
        finally:
            FINALLY_BLOCK

Was dann wie folgt verwendet werden kann

with my_template(*args):
    TRY_BLOCK

Es gibt jedoch zwei wichtige semantische Unterschiede zwischen diesem Code und der ursprünglichen try-Anweisung.

Erstens, in der ursprünglichen try-Anweisung, wenn eine break-, return- oder continue-Anweisung in TRY_BLOCK angetroffen wird, wird nur FINALLY_BLOCK ausgeführt, während die Anweisung abgeschlossen wird. Mit dem Statement-Template wird auch ELSE_BLOCK ausgeführt, da diese Anweisungen wie jede andere nicht-ausnahmebedingte Blockbeendigung behandelt werden. Für Anwendungsfälle, bei denen dies wichtig ist, ist dies wahrscheinlich eine gute Sache (siehe transaction in den Beispielen), da diese Lücke, in der weder die except- noch die else-Klausel ausgeführt wird, leicht zu vergessen ist, wenn man Ausnahmebehandler schreibt.

Zweitens wird das Statement-Template keine Ausnahmen unterdrücken. Wenn beispielsweise der ursprüngliche Code die Ausnahmen exc_type1 und exc_type2 unterdrückt hätte, dann müsste dies immer noch inline im Benutzercode geschehen

try:
    with my_template(*args):
        TRY_BLOCK
except (exc_type1, exc_type2):
    pass

Jedoch ist selbst in diesen Fällen, in denen die Unterdrückung von Ausnahmen explizit gemacht werden muss, die Menge an Boilerplate, die an der Aufrufstelle wiederholt wird, signifikant reduziert (Siehe Abgelehnte Optionen für weitere Diskussionen über dieses Verhalten).

Im Allgemeinen werden nicht alle Klauseln benötigt. Für die Ressourcenverwaltung (wie Dateien oder Synchronisationsschlösser) ist es möglich, den Code, der Teil von FINALLY_BLOCK in der __exit__()-Methode gewesen wäre, einfach auszuführen. Dies kann in der folgenden Implementierung gesehen werden, die Synchronisationsschlösser in Statement-Templates umwandelt, wie eingangs dieser Sektion erwähnt

# New methods of synchronisation lock objects

def __enter__(self):
    self.acquire()
    return self

def __exit__(self, *exc_info):
    self.release()

Standardwert für yield

Beim Erstellen eines Statement-Templates mit einem Generator wird die yield-Anweisung oft nur dazu verwendet, die Kontrolle an den Körper der benutzerdefinierten Anweisung zurückzugeben, anstatt einen nützlichen Wert zurückzugeben.

Entsprechend, wenn dieser PEP akzeptiert wird, wird yield, wie return, einen Standardwert von None liefern (d. h. yield und yield None werden zu äquivalenten Anweisungen).

Diese gleiche Änderung wird in PEP 342 vorgeschlagen. Offensichtlich müsste sie nur einmal implementiert werden, wenn beide PEPs akzeptiert würden :)

Template-Generator-Decorator: statement_template

Wie bei PEP 343 wird ein neuer Decorator vorgeschlagen, der einen Generator in ein Objekt mit der entsprechenden Statement-Template-Semantik verpackt. Im Gegensatz zu PEP 343 sind die hier vorgeschlagenen Templates wiederverwendbar, da der Generator bei jedem Aufruf von __enter__() neu instanziiert wird. Zusätzlich werden alle Ausnahmen, die in BLOCK1 auftreten, im internen Frame des Generators erneut ausgelöst.

class template_generator_wrapper(object):

    def __init__(self, func, func_args, func_kwds):
         self.func = func
         self.args = func_args
         self.kwds = func_kwds
         self.gen = None

    def __enter__(self):
        if self.gen is not None:
            raise RuntimeError("Enter called without exit!")
        self.gen = self.func(*self.args, **self.kwds)
        try:
            return self.gen.next()
        except StopIteration:
            raise RuntimeError("Generator didn't yield")

    def __exit__(self, *exc_info):
        if self.gen is None:
            raise RuntimeError("Exit called without enter!")
        try:
            try:
                if exc_info[0] is not None:
                    self.gen._inject_exception(*exc_info)
                else:
                    self.gen.next()
            except StopIteration:
                pass
            else:
                raise RuntimeError("Generator didn't stop")
        finally:
            self.gen = None

def statement_template(func):
    def factory(*args, **kwds):
        return template_generator_wrapper(func, args, kwds)
    return factory

Template-Generator-Wrapper: __enter__()-Methode

Der Template-Generator-Wrapper hat eine __enter__()-Methode, die eine neue Instanz des enthaltenen Generators erstellt und dann next() einmal aufruft. Sie löst eine RuntimeError aus, wenn die letzte Generatorinstanz nicht aufgeräumt wurde oder wenn der Generator endet, anstatt einen Wert zu liefern.

Template-Generator-Wrapper: __exit__()-Methode

Die Template-Generator-Wrapper-Methode hat eine __exit__()-Methode, die einfach next() auf dem Generator aufruft, wenn keine Ausnahme übergeben wird. Wenn eine Ausnahme übergeben wird, wird sie im enthaltenen Generator an der Stelle der letzten yield-Anweisung erneut ausgelöst.

In beiden Fällen löst der Generator-Wrapper eine RuntimeError aus, wenn der interne Frame infolge der Operation nicht beendet wird. Die __exit__()-Methode räumt immer die Referenz auf die verwendete Generatorinstanz auf, was es ermöglicht, __enter__() erneut aufzurufen.

Eine von der __exit__()-Methode des Template-Generator-Wrappers ausgelöste StopIteration kann versehentlich unterdrückt werden, aber das ist unwichtig, da die ursprünglich ausgelöste Ausnahme weiterhin korrekt weitergegeben wird.

Ausnahmen in Generatoren injizieren

Um die __exit__()-Methode des Template-Generator-Wrappers zu implementieren, ist es notwendig, Ausnahmen in den internen Frame des Generators zu injizieren. Dies ist ein neues Verhalten auf Implementierungsebene, das derzeit keine Entsprechung in Python hat.

Der Injektionsmechanismus (in diesem PEP als _inject_exception bezeichnet) löst eine Ausnahme im Frame des Generators mit dem angegebenen Typ, Wert und Traceback-Informationen aus. Das bedeutet, dass die Ausnahme wie die ursprüngliche aussieht, wenn sie weitergegeben werden darf.

Für die Zwecke dieses PEP ist es nicht notwendig, diese Fähigkeit außerhalb des Python-Implementierungscodes verfügbar zu machen.

Generator-Finalisierung

Zur Unterstützung der Ressourcenverwaltung in Template-Generatoren wird in diesem PEP die Beschränkung für yield-Anweisungen innerhalb des try-Blocks einer try/finally-Anweisung aufgehoben. Folglich können Generatoren, die die Verwendung einer Datei oder eines ähnlichen Objekts erfordern, sicherstellen, dass das Objekt durch die Verwendung von try/finally- oder with-Anweisungen korrekt verwaltet wird.

Diese Einschränkung muss wahrscheinlich global aufgehoben werden – es wäre schwierig, sie so einzuschränken, dass sie nur innerhalb von Generatoren zulässig ist, die zur Definition von Statement-Templates verwendet werden. Entsprechend enthält dieser PEP Vorschläge, die sicherstellen, dass Generatoren, die nicht als Statement-Templates verwendet werden, dennoch ordnungsgemäß finalisiert werden.

Generator-Finalisierung: TerminateIteration-Ausnahme

Eine neue Ausnahme wird vorgeschlagen

class TerminateIteration(Exception): pass

Die neue Ausnahme wird in einen Generator injiziert, um die Finalisierung anzufordern. Sie sollte von gut funktionierendem Code nicht unterdrückt werden.

Generator-Finalisierung: __del__()-Methode

Um sicherzustellen, dass ein Generator irgendwann finalisiert wird (innerhalb der Grenzen der Python-Garbage-Collection), erhalten Generatoren eine __del__()-Methode mit folgender Semantik

def __del__(self):
    try:
        self._inject_exception(TerminateIteration, None, None)
    except TerminateIteration:
        pass

Deterministische Generator-Finalisierung

Es gibt eine einfache Möglichkeit, eine deterministische Finalisierung von Generatoren zu gewährleisten: ihnen entsprechende __enter__() und __exit__() Methoden zu geben

def __enter__(self):
    return self

def __exit__(self, *exc_info):
    try:
        self._inject_exception(TerminateIteration, None, None)
    except TerminateIteration:
        pass

Dann kann jeder Generator prompt finalisiert werden, indem die relevante for-Schleife in eine with-Anweisung eingepackt wird

with all_lines(filenames) as lines:
    for line in lines:
        print lines

(Siehe die Beispiele für die Definition von all_lines und den Grund, warum sie eine sofortige Finalisierung erfordert)

Vergleichen Sie das obige Beispiel mit der Verwendung von Dateiobjekten

with open(filename) as f:
    for line in f:
        print f

Generatoren als benutzerdefinierte Statement-Templates

Wenn ein Generator zur Implementierung einer benutzerdefinierten Anweisung verwendet wird, sollte er auf jedem gegebenen Kontrollpfad nur einmal einen Wert liefern. Das Ergebnis dieser `yield`-Anweisung wird dann als Ergebnis der `__enter__()`-Methode des Generators bereitgestellt. Eine einzige `yield`-Anweisung auf jedem Kontrollpfad stellt sicher, dass der interne Frame beendet wird, wenn die `__exit__()`-Methode des Generators aufgerufen wird. Mehrere `yield`-Anweisungen auf einem einzigen Kontrollpfad führen dazu, dass die `__exit__()`-Methode eine `RuntimeError` auslöst, wenn der interne Frame nicht korrekt beendet wird. Ein solcher Fehler zeigt einen Fehler in der Statement-Vorlage an.

Um auf Ausnahmen zu reagieren oder Ressourcen freizugeben, reicht es aus, die yield-Anweisung in eine entsprechend konstruierte try-Anweisung zu packen. Wenn die Ausführung nach dem yield ohne Ausnahme fortgesetzt wird, weiß der Generator, dass der Körper der do-Anweisung ohne Zwischenfall abgeschlossen wurde.

Die grundlegende Konstruktion als Schleifenkonstrukt zu haben

Das Hauptproblem mit dieser Idee, wie durch PEP 340s block-Anweisungen veranschaulicht, ist, dass sie Probleme mit der Faktorisierung von try-Anweisungen innerhalb von Schleifen verursacht, die break- und continue-Anweisungen enthalten (da diese Anweisungen dann auf das block-Konstrukt und nicht auf die ursprüngliche Schleife angewendet würden). Da ein Hauptziel darin besteht, beliebige Ausnahmebehandlung (außer Unterdrückung) in Statement-Templates faktorisieren zu können, ist dies ein deutliches Problem.

Es gibt auch ein Verständlichkeitsproblem, wie in den Beispielen zu sehen ist. Im Beispiel, das den Erwerb eines Schlosses entweder für eine gesamte Schleife oder für jede Iteration der Schleife zeigt, würde die Verschiebung der benutzerdefinierten Anweisung von außerhalb der for-Schleife nach innen in die for-Schleife wesentliche semantische Auswirkungen haben, die über die erwarteten hinausgehen, wenn die benutzerdefinierte Anweisung selbst eine Schleife wäre.

Schließlich gibt es bei einem Schleifenkonstrukt erhebliche Probleme mit TOOWTDI (There's Only One Way To Do It), da oft unklar ist, ob eine bestimmte Situation mit einer herkömmlichen for-Schleife oder dem neuen Schleifenkonstrukt behandelt werden sollte. Mit dem aktuellen PEP gibt es kein solches Problem – for-Schleifen werden weiterhin für die Iteration verwendet, und die neuen do-Anweisungen werden verwendet, um Ausnahmebehandlung zu faktorisieren.

Ein weiteres Problem, insbesondere bei PEP 340s anonymen Blockanweisungen, ist, dass sie es sehr schwierig machen, Statement-Templates direkt zu schreiben (d. h. nicht mit einem Generator). Dieses Problem wird durch den aktuellen Vorschlag gelöst, wie die relative Einfachheit der verschiedenen klassenbasierten Implementierungen von Statement-Templates in den Beispielen zeigt.

Statement-Templates zuzulassen, Ausnahmen zu unterdrücken

Frühere Versionen dieses PEP gaben Statement-Templates die Möglichkeit, Ausnahmen zu unterdrücken. Der BDFL äußerte Bedenken hinsichtlich der damit verbundenen Komplexität, und ich stimmte zu, nachdem ich einen Artikel von Raymond Chen über die Übel des Verbergens von Flusskontrolle in Makros in C-Code gelesen hatte [1].

Das Entfernen der Unterdrückungsfähigkeit hat eine ganze Menge Komplexität sowohl aus der Erklärung als auch aus der Implementierung von benutzerdefinierten Statements entfernt, was es weiter als die richtige Wahl unterstützt. Ältere Versionen des PEP mussten einige schreckliche Hürden überwinden, um unbeabsichtigte Ausnahmen in __exit__() Methoden zu vermeiden - dieses Problem existiert mit den aktuellen vorgeschlagenen Semantiken nicht.

Es gab ein Beispiel (auto_retry), das tatsächlich die Fähigkeit zur Unterdrückung von Ausnahmen nutzte. Dieser Anwendungsfall ist zwar nicht ganz so elegant, hat aber einen deutlich offensichtlicheren Kontrollfluss, wenn er vollständig im Benutzercode ausgeschrieben wird.

def attempts(num_tries):
    return reversed(xrange(num_tries))

for retry in attempts(3):
    try:
        make_attempt()
    except IOError:
        if not retry:
            raise

Was es wert ist, die Perversen könnten dies immer noch so schreiben:

for attempt in auto_retry(3, IOError):
    try:
        with attempt:
            make_attempt()
    except FailedAttempt:
        pass

Um die Unschuldigen zu schützen, ist der Code zur tatsächlichen Unterstützung hiervon hier nicht enthalten.

Unterscheidung zwischen nicht-ausnahmebedingten Beendigungen

Frühere Versionen dieses PEP erlaubten Statement-Vorlagen, zwischen dem normalen Verlassen des Blocks und dem Verlassen durch eine return, break oder continue Anweisung zu unterscheiden. Der BDFL spielte mit einer ähnlichen Idee in PEP 343 und der damit verbundenen Diskussion. Dies fügte der Beschreibung der Semantiken erhebliche Komplexität hinzu und erforderte, dass jede einzelne Statement-Vorlage entschied, ob diese Anweisungen wie Ausnahmen behandelt werden sollten oder wie ein normaler Mechanismus zum Verlassen des Blocks.

Dieser Template-zu-Template-Entscheidungsprozess führte zu großem Verwirrungspotenzial - stellen Sie sich vor, ein Datenbankverbinder würde eine Transaktionsvorlage bereitstellen, die frühe Ausgänge wie eine Ausnahme behandelt, während ein zweiter Verbinder sie als normale Blockterminierung behandelt.

Entsprechend verwendet dieser PEP nun die einfachste Lösung - frühe Ausgänge erscheinen aus Sicht der Statement-Vorlage identisch mit der normalen Blockterminierung.

Ausgelöste Ausnahmen nicht in Generatoren zu injizieren

PEP 343 schlägt vor, bei Generatoren, die zur Definition von Statement-Vorlagen verwendet werden, einfach bedingungslos next() aufzurufen. Das bedeutet, dass die Vorlagen-Generatoren eher unintuitiv aussehen, und die Beibehaltung des Verbots von yield innerhalb von try/finally bedeutet, dass die Ausnahmebehandlungsfähigkeiten von Python nicht zur Verwaltung mehrerer Ressourcen verwendet werden können.

Die Alternative, die dieser PEP befürwortet (Einspeisen von ausgelösten Ausnahmen in den Generator-Frame), bedeutet, dass mehrere Ressourcen elegant verwaltet werden können, wie durch lock_opening in den Beispielen gezeigt.

Alle Generatoren zu Statement-Templates zu machen

Die Trennung des Vorlageobjekts vom Generator selbst ermöglicht wiederverwendbare Vorlagen-Generatoren. Das heißt, der folgende Code funktioniert korrekt, wenn dieser PEP akzeptiert wird.

open_it = lock_opening(parrot_lock, "dead_parrot.txt")

with open_it as f:
    # use the file for a while

with open_it as f:
    # use the file again

Der zweite Vorteil ist, dass Iterator-Generatoren und Vorlagen-Generatoren sehr unterschiedliche Dinge sind - der Dekorator hält diese Unterscheidung klar und verhindert, dass einer dort verwendet wird, wo der andere benötigt wird.

Schließlich ermöglicht die Anforderung des Dekorators, dass die nativen Methoden von Generatorobjekten zur Implementierung der Generator-Finalisierung verwendet werden.

Das Schlüsselwort do zu verwenden

do war ein alternatives Schlüsselwort, das während der PEP 340 Diskussion vorgeschlagen wurde. Es liest sich gut mit entsprechend benannten Funktionen, aber es liest sich schlecht, wenn es mit Methoden oder mit Objekten verwendet wird, die native Statement-Vorlagenunterstützung bieten.

Als do zum ersten Mal vorgeschlagen wurde, hatte der BDFL PEP 310's with Schlüsselwort abgelehnt, basierend auf dem Wunsch, es für ein Pascal/Delphi-Stil with Statement zu verwenden. Seitdem hat der BDFL dieses Bedenken zurückgezogen, da er ein solches Statement nicht mehr beabsichtigt. Diese Herzensänderung basierte anscheinend auf den Gründen der C#-Entwickler, die Funktion nicht bereitzustellen [2].

Kein Schlüsselwort zu haben

Dies ist eine interessante Option und kann recht gut lesbar gemacht werden. Es ist jedoch für neue Benutzer umständlich in der Dokumentation nachzuschlagen und wirkt auf manche zu magisch. Entsprechend verfolgt dieser PEP einen schlüsselwortbasierten Vorschlag.

Verbesserung von try-Anweisungen

Dieser Vorschlag beinhaltet, try Anweisungen eine Signatur zu geben, die der für with Anweisungen vorgeschlagenen ähnelt.

Ich denke, dass der Versuch, ein with Statement als erweitertes try Statement zu schreiben, genauso sinnvoll ist, wie zu versuchen, eine for Schleife als erweitertes while Statement zu schreiben. Das heißt, während die Semantik des ersteren als eine bestimmte Art der Verwendung des letzteren erklärt werden kann, ist ersteres keine *Instanz* des letzteren. Die zusätzlichen Semantiken, die um das grundlegendere Statement hinzugefügt werden, ergeben ein neues Konstrukt, und die beiden unterschiedlichen Statements sollten nicht verwechselt werden.

Dies zeigt sich daran, dass das „erweiterte“ try Statement immer noch in Bezug auf ein „nicht-erweitertes“ try Statement erklärt werden muss. Wenn es etwas anderes ist, ist es sinnvoller, ihm einen anderen Namen zu geben.

Das Template-Protokoll direkt try-Anweisungen widerspiegeln zu lassen

Ein Vorschlag war, separate Methoden im Protokoll zu haben, die verschiedene Teile der Struktur eines verallgemeinerten try Statements abdecken. Unter Verwendung der Begriffe try, except, else und finally hätten wir etwas wie:

class my_template(object):

    def __init__(self, *args):
        # Any required arguments (e.g. a file name)
        # get stored in member variables
        # The various BLOCK's will need to updated to reflect
        # that.

    def __try__(self):
        SETUP_BLOCK

    def __except__(self, exc, value, traceback):
        if isinstance(exc, exc_type1):
            EXCEPT_BLOCK1
        if isinstance(exc, exc_type2):
            EXCEPT_BLOCK2
        else:
            EXCEPT_BLOCK3

    def __else__(self):
        ELSE_BLOCK

    def __finally__(self):
        FINALLY_BLOCK

Abgesehen davon, dass die Hinzufügung von zwei Methodenslots anstelle von vier bevorzugt wird, halte ich es für erheblich einfacher, einfach eine leicht modifizierte Version des ursprünglichen try Statement-Codes in der __exit__() Methode (wie in Factoring out arbitrary exception handling gezeigt) reproduzieren zu können, anstatt die Funktionalität auf mehrere verschiedene Methoden aufzuteilen (oder herauszufinden, welche Methode verwendet werden soll, wenn nicht alle Klauseln vom Template verwendet werden).

Um diese Diskussion weniger theoretisch zu gestalten, hier ist das transaction Beispiel, das sowohl mit dem Zwei-Methoden- als auch mit dem Vier-Methoden-Protokoll anstelle eines Generators implementiert ist. Beide Implementierungen garantieren einen Commit, wenn eine break, return oder continue Anweisung angetroffen wird (ebenso wie die Generator-basierte Implementierung im Abschnitt Beispiele).

class transaction_2method(object):

    def __init__(self, db):
        self.db = db

    def __enter__(self):
        pass

    def __exit__(self, exc_type, *exc_details):
        if exc_type is None:
            self.db.commit()
        else:
            self.db.rollback()

class transaction_4method(object):

    def __init__(self, db):
        self.db = db
        self.commit = False

    def __try__(self):
        self.commit = True

    def __except__(self, exc_type, exc_value, traceback):
        self.db.rollback()
        self.commit = False

    def __else__(self):
        pass

    def __finally__(self):
        if self.commit:
            self.db.commit()
            self.commit = False

Es gibt noch zwei weitere kleinere Punkte, die sich auf die spezifischen Methodennamen im Vorschlag beziehen. Der Name der __try__() Methode ist irreführend, da SETUP_BLOCK *vor* dem Betreten der try Anweisung ausgeführt wird, und der Name der __else__() Methode ist isoliert betrachtet unklar, da zahlreiche andere Python-Anweisungen eine else Klausel enthalten.