Generators and exceptions (was Re: Stackless Python and Python 2.x)

[Tim Peters]

[Aahz]
> Gotcha.  So after the generator gets suspended, the call chain in using
> generators always refers to the frame in which g.next() executes.  I
> think adding that statement to the PEP would be helpful in reducing
> confusion.

Maybe, but I doubt it.  To date, you're the only one to have expressed
confusion on this point, and more words don't always clarify (to the
contrary, reference docs strive to use as few words as possible, partly to
reduce the possibilities for inconsistent phrasings).

> To expand on this a bit, essentially a generator lives in two contexts:
>
> * In the first context, a generator-iterator is created, but no code
> within the generator is executed.  This means that it is functionally
> impossible to raise an exception at this point (aside from the usual
> NameError if the generator object isn't found).  The generator is
> created in a suspended state; if g.next() is never called, the generator
> will never do anything.

I think the PEP already explains this.  Phrases like "in the generator" just
create more possibilities for confusion; for example, and as the PEP says,
the actual arguments are bound to local names in the usual way (including
the establishment of default argument values), and that's part of every
function call (generator or not).  Is that "in the generator", or not?  The
PEP says "no code in the body of the function is executed", and I'd rather
leave it at that.

> * In the second context, g.next() activates the generator, which runs
> until it hits a yield, a return, or raises an exception.

Again I believe the PEP already explains all that.

> Whichever frame calls g.next() is considered the parent frame.

By the time you get to calling g.next(), you're merely using the iterator
protocol, so this doesn't need to be said.  Saying so anyway can be
counter-productive, in the same way drawing special attention to anything
that isn't actually special can obfuscate ("why are they saying this?  I
must be missing something subtle!").  As I said in the first reply, I
thought your view of generators was too complex, and now that you're
rephrasing the PEP in your own words (which is fine), you're pretty much
reduced to saying "oh! there's nothing special at all about this part":  in
*any* use of the iterator protocol (generator or not), the caller of
iterator.next() is (trivially) the caller of iterator.next().

> Using a single generator-iterator object across multiple threads is
> Bad Idea (with the usual caveats about careful locking).

Again that's nothing unique to generators.

> (Yes, I think all of this is in the PEP, but I think the PEP could use a
> clear summary like this.

Sorry, but I didn't find it clearer than the existing text, and indeed I
find it confusing to belabor the obvious.  This level of hand-holding would
be appropriate in a self-described *tutorial*, though.

> Or I suppose I could try writing up something for Fred to use in the
> docs -- I don't see anything in the dev docs about generators.)

I'm afraid a great many 2.2 features remain to be documented.

and-generators-are-minor-compared-to-the-new-type/class-stuff-ly y'rs
    - tim