[Python-Dev] why not "return StopIteration"?

Thomas Wouters thomas@xs4all.net
Fri, 22 Jun 2001 20:02:59 +0200

On Fri, Jun 22, 2001 at 01:21:03PM -0400, Tim Peters wrote:

>  If this stands, I'm going to look into
> changing gen_iternext() to determine whether eval_frame() finished by
> raising StopIteration, and mark the iterator as done if so.  That is, force
> "return" and "raise StopIteration" to act the same inside generators, and to
> force "raise StopIteration" inside a generator to truly *mean* "I'm done" in
> all cases.  This would also allow to avoid the proposed special-casing of
> generators at the tail end of eval_frame() (yes, I'm anal <0.9 wink>:  since
> it's a problem unique to generators, this simply should not be eval_frame's
> problem to solve -- if generators create the problem, generators should pay
> to solve it).

I don't get this. Currently, (unless Just checked in his patch) generators
work in exactly that way: the compiler compiles 'return' into 'raise
StopIteration' if it encounters it inside a generator, and into a regular
return otherwise. Why would you ask for the patch Just provided, and then
change it back ?

Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!