Tim Peters wrote:
Who would this help? Seriously. There's nothing special about a generator to a caller, except that it returns an object that implements the iterator interface.
What matters to the caller is irrelevant here. We're talking about what matters to someone writing or reading the implementation. To those people, there is a VERY big difference between a regular function and a generator-function -- about as big as the difference between a class and a function! In fact, a generator-function is in many ways much more like a class than a function. Calling a generator-function doesn't execute any of the code in its body; instead, it creates an instance of the generator, much like calling a class creates an instance of the class. Calling them "generator classes" and "generator instances" would perhaps be more appropriate, and more suggestive of the way they actually behave. The more I think about this, the more I agree with those who say that overloading the function-definition syntax for defining generators is a bad idea. It seems to make about as much sense as saying that there shouldn't be any special syntax for defining a class -- the header of a class definition should look exactly like a function definition, and to tell the difference you have to look for some subtle clue further down. I suggest dropping the "def" altogether and using: generator foo(args): ... yield x ... Right from the word go, this says loudly and clearly that this thing is *not* a function, it's something else. If you haven't come across generators before, you go and look in the manual to find out what it means. There you're told something like Executing a generator statement creates a special callable object called a generator. Calling a generator creates a generator-instance, which is an iterator object... [...stuff about the "yield" statement...] I think this is going to be easier to document and lead to much less confusion than trying to explain the magic going on when you call something that looks for all the world like a function and it doesn't execute any of the code in it. Explicit is better than implicit! -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand To get my email address, please visit my web page: http://www.cosc.canterbury.ac.nz/~greg