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