[Python-checkins] python/nondist/peps pep-0340.txt,1.11,1.12

[gvanrossum at users.sourceforge.net]

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

Modified Files:
	pep-0340.txt 
Log Message:
Add a section of loose ends.


Index: pep-0340.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0340.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- pep-0340.txt	29 Apr 2005 17:13:08 -0000	1.11
+++ pep-0340.txt	29 Apr 2005 18:51:03 -0000	1.12
@@ -36,19 +36,19 @@
 
     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__()
+    a value or an exception, we use a separate API (an __exit__()
     method taking an exception and perhaps a traceback) for the
-    exception.  If an iterator doesn't implement __error__(), the
+    exception.  If an iterator doesn't implement __exit__(), the
     exception is just re-raised.  It is expected that, apart from
-    generators, very few iterators will implement __error__(); one use
+    generators, very few iterators will implement __exit__(); 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__().
-
-    Perhaps __error__() should be named __exit__().
+    __exit__().  (Or perhaps calling next(itr, exc, traceback) would
+    call itr.__exit__(exc, traceback) if itr has an __exit__ method
+    and otherwise raise exc.__class__, exc, traceback?)
 
 Motivation and Summary
 
@@ -432,6 +432,32 @@
     EXPR2" is changed; break and return translate to themselves in
     that case).
 
+Loose Ends
+
+    These are things that need to be resolved before accepting the
+    PEP.
+
+    - Fill in the remaining TBD sections.
+
+    - Address Phillip Eby's proposal to have the block-statement use
+      an entirely different API than the for-loop, to differentiate
+      between the two (a generator would have to be wrapped in a
+      decorator to make it support the block API).
+
+    - Decide on the keyword ('block', 'with', '@', nothing, or
+      something else?).
+
+    - Phillip Eby wants a way to pass tracebacks along with
+      exceptions.
+
+    - The translation for the for-loop's else-clause.
+
+    - Whether a block-statement should allow an else-clause.
+
+    - Which API to use to pass in an exception: itr.__next__(exc),
+      itr.__next__(exc, True) or itr.__exit__(exc[, traceback]).
+      Hmm..., perhaps itr.__next__(exc, traceback)?
+
 Comparison to Thunks
 
     Alternative semantics proposed for the block-statement turn the