[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 -- http://mail.python.org/mailman/listinfo/python-list
