Advanced warning that another rewrite of the exception handling

mechanics is pending.

pep-0340.txt

@@ -26,6 +26,28 @@ Introduction
     this on python-dev recently [1], and I figured it would be time to
     write up a precise spec in PEP form.
 
+Proposal Evolution
+
+    The discussion on python-dev has changed my mind slightly on how
+    exceptions should be handled, but I don't have the time to do a
+    full update of the PEP right now.  Basically, I'm now in favor of
+    a variation on the exception handling proposed in the section
+    "Alternative __next__() and Generator Exception Handling" below.
+
+    The added twist is that instead of adding a flag argument to
+    next() and __next__() to indicate whether the previous argument is
+    a value or an exception, we use a separate API (an __error__()
+    method taking an exception and perhaps a traceback) for the
+    exception.  If an iterator doesn't implement __error__(), the
+    exception is just re-raised.  It is expected that, apart from
+    generators, very few iterators will implement __error__(); one use
+    case would be a fast implementation of synchronized() written in
+    C.
+
+    The built-in next() function only interfaces to the next() and
+    __next__() methods; there is no user-friendly API to call
+    __error__().
+
 Motivation and Use Cases
 
     TBD.