PEP 288 ponderings

[Steven Bethard]

Raymond Hettinger wrote:
> [Steven Bethard]
>>(2) Since in all the examples there's a one-to-one correlation between
>>setting a generator attribute and calling the generator's next function,
>>aren't these generator attribute assignments basically just trying to
>>define the 'next' parameter list?
> 
> They are not the same.  The generator needs some way to receive the values.  The
> function arguments cannot be used because they are needed to create the
> generator-iterator.  The yield statements likewise won't work because the first
> yield is not encountered until well after the first next() call.

Yeah, I wasn't trying to claim that passing the arguments to .next() is 
equivalent to generator attributes, only that the point at which new 
values for the generator state variables are provided correspond with 
calls to .next().  So if there was a means within a generator of getting 
access to the arguments passed to .next(), generator attributes would be 
unnecessary for the examples provided.

> The given examples are minimal and are intended only to demonstrate the idea.

Do you have an example where the generator state isn't updated in 
lock-step with .next() calls?  I'd be interested to look at an example 
of this...

>>I definitely don't like the
>>idea of a magical __self__ variable that isn't declared anywhere.
> 
> It is no more magical than f.__name__ or f.__doc__ for functions.

I'm not sure this is quite a fair parallel.  The difference here is that 
  f.__name__ and f.__doc__ are accessed as attributes of the f object, 
and the __name__ and __doc__ attributes are created as a result of 
function creation.  The proposed __self__ is (1) not an attribute that 
becomes available, rather, a new binding local to the function, and (2) 
not created as a result of generator object creation but created as a 
result of calling .next() on the generator object.

> Also, the __self__ argument is a non-issue because there are other alternate
> approaches such as providing a function that retrieves the currently
> running generator.

Is there a discussion of some of these alternate suggested approaches 
somewhere you could point me to?

> The more important part of the PEP is the idea for generator exceptions.  The
> need arises in the context of flushing/closing resources upon generator
> termination.

I wonder if maybe it would be worth moving this part to a separate PEP. 
  It seems like it could probably stand on its own merit, and having it 
in with the generator attributes PEP means it isn't likely to be 
accepted separately.

Of course, I would probably declare a class and provide a .close() 
method. =)

Steve