[Python-Dev] PEP 343 rewrite complete

[Guido van Rossum]

[me]
> I'll summarize this discussion in the PEP.

I've added this section to the PEP. Is anyone dead set against the
tentative resolutions here?

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.


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)