[Python-checkins] python/nondist/peps pep-0343.txt,1.19,1.20
gvanrossum@users.sourceforge.net
gvanrossum at users.sourceforge.net
Thu Jun 2 16:56:39 CEST 2005
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12669
Modified Files:
pep-0343.txt
Log Message:
Raise RuntimeError in close(). Add list of open issues.
Index: pep-0343.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0343.txt,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- pep-0343.txt 1 Jun 2005 21:01:11 -0000 1.19
+++ pep-0343.txt 2 Jun 2005 14:56:36 -0000 1.20
@@ -306,11 +306,9 @@
except (GeneratorExit, StopIteration):
pass
else:
- raise TypeError("generator ignored GeneratorExit")
+ raise RuntimeError("generator ignored GeneratorExit")
# Other exceptions are not caught
- (XXX is TypeError an acceptable exception here?)
-
New generator method: __del__()
g.__del__() is an alias for g.close(). This will be called when
@@ -417,6 +415,50 @@
OTOH such mistakes are easily diagnosed.
+Open Issues
+
+ Discussion on python-dev has revealed some open issues. I list
+ them here, with my preferred resolution and its motivation. The
+ PEP as currently written reflects this preferred resolution.
+
+ 1. What exception should be raised by close() when the generator
+ yields another value as a response to the GeneratorExit
+ exception?
+
+ I originally chose TypeError because it represents gross
+ misbehavior of the generator function, which should be fixed by
+ changing the code. But the with_template decorator class uses
+ RuntimeError for similar offenses. Arguably they should all
+ use the same exception. I'd rather not introduce a new
+ exception class just for this purpose, since it's not an
+ exception that I want people to catch: I want it to turn into a
+ traceback which is seen by the programmer who then fixes the
+ code. So now I believe they should both raise RuntimeError.
+ There are some precedents for that: it's raised by the core
+ Python code in situations where endless recursion is detected,
+ and for uninitialized objects (and for a variety of
+ miscellaneous conditions).
+
+ 2. Both the generator close() method and the __exit__() method of
+ the with_template decorator class catch StopIteration and
+ consider it equivalent to re-raising the exception passed to
+ throw(). Is allowing StopIteration right here?
+
+ This is so that a generator doing cleanup depending on the
+ exception thrown (like the transactional() example below) can
+ *catch* the exception thrown if it wants to and doesn't have to
+ worry about re-raising it. I find this more convenient for the
+ generator writer. Against this was brought in that the
+ generator *appears* to suppress an exception that it cannot
+ suppress: the transactional() example would be more clear
+ according to this view if it re-raised the original exception
+ after the call to db.rollback(). I personally would find the
+ requirement to re-raise the exception an annoyance in a
+ generator used as a with-template, since all the code after
+ yield is used for is cleanup, and it is invoked from a
+ finally-clause (the one implicit in the with-statement) which
+ re-raises the original exception anyway.
+
Examples
(Note: several of these examples contain "yield None". If PEP 342
More information about the Python-checkins
mailing list