Long overdue updates.

A decision one way or the other should be made wrt. this PEP at some
point, I guess.

pep-0310.txt

@@ -66,9 +66,11 @@ Basic Syntax and Semantics
 	    suite
 
 	finally:
-	    if hasattr(var, "__exit__"):
             var.__exit__()
 
+    Note that this makes using an object that does not have an
+    __exit__() method a fail-fast error.
+
     If the variable is omitted, an unnamed object is allocated on the
     stack.  In that case, the suite has no access to the unnamed object.
 
@@ -117,18 +119,6 @@ Possible Extensions
 
 Implementation Notes
 
-    The optional assignment in
-
-        'with' [ var '=' ] expr ':'
-
-    was initially considered to be too hard to parse correctly.
-    However, by parsing the statement as
-
-        'with' expr [ '=' expr ] ':'
-
-    and interpreting the result in the compiler phase, this can be
-    worked around.
-
     There is a potential race condition in the code specified as
     equivalent to the with statement.  For example, if a
     KeyboardInterrupt exception is raised between the completion of
@@ -157,8 +147,19 @@ Open Issues
 
     If a way of controlling object lifetimes explicitly was available,
     the function of the __exit__ hook could be taken over by the
-    existing __del__ hook.  Unfortunately, no workable proposal for
-    controlling object lifetimes has been made so far.
+    existing __del__ hook.  An email exchange[1] with a proponent of
+    this approach left one of the authors even more convinced that
+    it isn't the right idea...
+
+    It has been suggested[2] that the "__exit__" method be called
+    "close", or that a "close" method should be considered if no
+    __exit__ method is found, to increase the "out-of-the-box utility"
+    of the "with ..." construct.
+
+    There are some simiralities in concept between 'with ...' blocks
+    and generators, which have led to proposals that for loops could
+    implement the with block functionality[3].  While neat on some
+    levels, we think that for loops should stick to being loops.
 
 
 Alternative Ideas
@@ -166,6 +167,17 @@ Alternative Ideas
     IEXEC: Holger Krekel -- generalised approach with XML-like syntax
                             (no URL found...)
 
+    Holger has much more far-reaching ideas about "execution monitors"
+    that are informed about details of control flow in the monitored
+    block.  While interesting, these ideas could change the language
+    in deep and subtle ways and as such belong to a different PEP.
+
+    Any Smalltalk/Ruby anonymous block style extension obviously
+    subsumes this one.
+
+    PEP 319 is in the same area, but did not win support when aired on
+    python-dev.
+
 
 Backwards Compatibility
 
@@ -173,11 +185,45 @@ Backwards Compatibility
     to be played.
 
 
+Cost of Adoption
+
+    Those who claim the language is getting larger and more
+    complicated have something else to complain about.  It's something
+    else to teach.
+
+    For the proposal to be useful, many file-like and lock-like
+    classes in the standard library and other code will have to have
+
+        __exit__ = close
+
+    or similar added.
+
+
+Cost of Non-Adoption
+
+    Writing correct code continues to be more effort than writing
+    incorrect code.
+
+
 References
 
     There are various python-list and python-dev discussions that
     could be mentioned here.
 
+    [1] Off-list conversation between Michael Hudson and Bill Soudan
+        (made public with permission)
+        http://starship.python.net/crew/mwh/pep310/
+
+    [2] Samuele Pedroni on python-dev
+        http://mail.python.org/pipermail/python-dev/2003-August/037795.html
+
+    [3] Thread on python-dev with subject
+
+        [Python-Dev] pre-PEP: Resource-Release Support for Generators
+
+        starting at
+
+        http://mail.python.org/pipermail/python-dev/2003-August/037803.html
 
 Copyright
 
@@ -191,4 +237,3 @@ indent-tabs-mode: nil
 sentence-end-double-space: t
 fill-column: 70
 End:
-