[Python-checkins] python/nondist/peps pep-0340.txt,1.6,1.7

gvanrossum at users.sourceforge.net gvanrossum at users.sourceforge.net
Thu Apr 28 01:10:47 CEST 2005

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28210

Modified Files:
Log Message:
Advanced warning that another rewrite of the exception handling
mechanics is pending.

Index: pep-0340.txt
RCS file: /cvsroot/python/python/nondist/peps/pep-0340.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- pep-0340.txt	27 Apr 2005 22:41:48 -0000	1.6
+++ pep-0340.txt	27 Apr 2005 23:10:42 -0000	1.7
@@ -26,6 +26,28 @@
     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

More information about the Python-checkins mailing list