PEP 288 ponderings

[Raymond Hettinger]

[Steven Bethard]
> (1) What's the benefit of the generator versions of these functions over
> the class-based versions?

Generators are easier to write, are clearer, and run faster.

They automatically
* create a distinct generator-iterator object upon each invocation
* create the next() and idempotent __iter__() methods.
* raise StopIteration  upon termination
* remain stopped if next() is called too many times
* save their own local variable state, avoiding the need for self.var references
* resume execution at the point of the last yield



> (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.

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



> 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.  The concept
is almost identical to that for threading.local().  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.  Which approach is
ultimately taken is a matter of aesthetics -- the PEP itself concentrates on the
core idea instead of debating syntax.

The real issue with PEP 288's idea for generator attributes is that the current
C implementation doesn't readily accommodate this change.  Major surgery would
be required :-(

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.



Raymond Hettinger