Explain the __exit__() signature.

pep-0343.txt

@@ -185,6 +185,23 @@ Specification
     with three arguments representing the exception type, value, and
     traceback.
 
+    The motivation for this API to __exit__(), as opposed to the
+    argument-less __exit__() from PEP 310, was given by the
+    transactional() use case, example 3 below.  The template in that
+    example must commit or roll back the transaction depending on
+    whether an exception occurred or not.  Rather than just having a
+    boolean flag indicating whether an exception occurred, we pass the
+    complete exception information, for the benefor of an
+    exception-logging facility for example.  Relying on sys.exc_info()
+    to get att the exception information was rejected; sys.exc_info()
+    has very complex semantics and it is perfectly possible that it
+    returns the exception information for an exception that was caught
+    ages ago.  It was also proposed to add an additional boolean to
+    distinguish between reaching the end of BLOCK and a non-local
+    goto.  This was rejected as too complex and unnecessary; a
+    non-local goto should be considered unexceptional for the purposes
+    of a database transaction roll-back decision.
+
 Optional Generator Decorator
 
     It is possible to write a decorator that makes it possible to use
@@ -300,7 +317,7 @@ Examples
             def __init__(self, db):
                 self.db = db
             def __enter__(self):
-                pass
+                self.db.begin()
             def __exit__(self, *args):
                 if args and args[0] is not None:
                     self.db.rollback()