[Greg Ewing]

...

Why is this on Python-Dev? The PEP announcement specifically asked for discussion to occur on the Iterators list, and specifically asked to keep it *off* of Python-Dev. I've been playing along with people who wanted to discuss it on c.l.py instead, as finite time allows, but no way does the discussion belong here.

...

...

...

...

"GE" == Greg Ewing writes:

GE> What matters to the caller is irrelevant here. We're talking GE> about what matters to someone writing or reading the GE> implementation. To those people, there is a VERY big GE> difference between a regular function and a GE> generator-function -- about as big as the difference GE> between a class and a function! GE> In fact, a generator-function is in many ways much more GE> like a class than a function. Calling a generator-function GE> doesn't execute any of the code in its body; instead, it GE> creates an instance of the generator, much like calling GE> a class creates an instance of the class. Calling them GE> "generator classes" and "generator instances" would GE> perhaps be more appropriate, and more suggestive of the GE> way they actually behave. Thanks Greg, I think you've captured perfectly my discomfort with the proposal. I'm fine with return being "special" inside a generator, along with most of the other details of the pep. But it bugs me that the semantics of calling the thing created by `def' is different depending on some statement embedded deep in the body of the code. Think about it from a teaching perspective: You're taught that def creates a function, perhaps called foo. You know that calling foo starts execution at the first line in the function block. You know you can put a print statement on the first line and it will print something out when the function is called. You know that you can set a debugger break point at foo's first line and when you call the function, the debugger will leave you on that first line of code. But all that changes with a generator! My print statement isn't executed when I call the function... how weird! Hey, the debugger doesn't even break on the line when I call the function. Okay, maybe it's some /other/ foo my program is really calling. So let's hunt around for other possible foo's that my program might be calling. Hmm, no dice there. Now I'm really confused because I haven't gotten to the chapter that says "Now that you know all about functions, forget most of that if you find a yield statement in the body of the function, because it's a special kind of function called a generator. Calling such a special function doesn't execute any code, it just instantiates a built-in object called a generator object. To get any of the generator's code to execute, you have to call the generator object's next() method." Further, I print out the type of the object returned by calling foo and I see it's a . Okay, so now let me search foo for a return statement. Because I know about functions, and I know that the returned object isn't None, I know that the function isn't falling off the end. So there must be a return statement that explicitly returns a generator object (whatever that is). Hmm, nope, there's just a bare return sitting there. That's damn confusing. I wonder what those yield statements are doing. Well, I look those up in my book's index and I see that's described in chapter 57, which I haven't gotten to yet. Besides, those yields clearly have integers after them, so that can't be it. So how the heck do I get a generator object by calling this function??? You'll counter that the "search for yield to find out if the function is special" is a simple rule, once learned is easily remembered. I'll counter that it's harder for me to do an Isearch in XEmacs to find out what kind of thing foo is. :) To me, it's just bad mojo to have the behavior of the thing created by `def' determined by what's embedded in the body of the program. I don't buy the defint argument, because by searching for a return statement in the function, you can find out exactly what is being returned when the function is called. Not so with a generator. My vote is for a "generator" keyword to introduce the code block of a generator. Makes perfect sense to me, and it will be a strong indication to anybody reading my code that something special is going on. And something special /is/ going on! An informal poll of PythonLabs indicates a split on this subject, perhaps setting Jeremy up as a Sandra Day O'Conner swing vote. But who said this was a democracy anyway? :) somewhat-like-my-own-country-of-origin-ly y'rs, -Barry

barry wrote:

My vote is for a "generator" keyword to introduce the code block of a generator. Makes perfect sense to me, and it will be a strong indication to anybody reading my code that something special is going on. And something special /is/ going on!

agreed. +1 on generator instead of def. (and +0 on suspend instead of yield, but that's me) Cheers /F

[Jeremy Hylton]

Why can't we discuss Python development on python-dev?

You can, but without me in this case. The arguments aren't new (they were discussed on the Iterators list before the PEP was posted), and I don't have time to repeat them on (now three) different forums. The PEP announcement clearly said discussion belonged on the Iterators list, specifically asked that it stay off of Python-Dev, and the PEP Discussion-To field (which I assume Barry filled in -- I did not) reads Discussion-To: python-iterators@lists.sourceforge.net If you want a coherent historic record (I do), that's where this belongs.

...

...

...

...

"TP" == Tim Peters writes:

TP> and the PEP Discussion-To field (which I assume Barry filled TP> in -- I did not) reads Not me. I believe it was in Magnus's original version of the PEP. But I do think that now that the code is in the main CVS trunk, it is appropriate to remove the Discussion-To: header and redirect comments back to python-dev. That may be difficult in practice however. -Barry

My vote is for a "generator" keyword to introduce the code block of a generator. Makes perfect sense to me, and it will be a strong indication to anybody reading my code that something special is going on. And something special /is/ going on!

An informal poll of PythonLabs indicates a split on this subject, perhaps setting Jeremy up as a Sandra Day O'Conner swing vote. But who said this was a democracy anyway? :)

somewhat-like-my-own-country-of-origin-ly y'rs, -Barry

That's a nice analogy, Ruth Barry Ginsburg; a Supreme Court, which appoints the president, seems a closer fit to Python's dictatorship than some sort of democratic process. I wasn't present for the oral arguments, but I'm sure we all know how Tim Scalia voted and that Guido van Clarence Thomas agreed without comment. I assume, then, that Anthony Kennedy Jr. joined you, although he's often a swing vote, too. Can't wait to hear the report from Nina "Michael Hudson" Totenberg. I was originally happy with the use of def. It's not much of a stretch since the def statement defines a code block that has formal parameters and creates a new scope. I certainly wouldn't be upset if Python ended up using def to define a generator. I appreciate, though, that the definition of a generator may look an awful lot like a function. I can imagine a user reading a module, missing the yield statement, and trying to use the generator as a function. I can't imagine this would happen often. My limited experience with CLU suggests that iterators aren't going to be huge, unwieldy blocks where it's hard to see what the ultimate control flow is. If a confused user treats a generator as a regular function, he or she certainly can't expect it to return anything useful, since all the return statements are bare returns; the expected behavior would be some side-effect on global state, which seems both unlikely and unseemly for an iterator. I'm not sure how hard it will be to explain generators to new users. I expect you would teach functions and iterations via for loop, then explain that there is a special kind of function called a generator that can be used in a for loop. It uses a yield statement instead of a return statement to return values. Not all that hard. If we use a different keyword to introduce them, you'd probably explain them much the same way: A generator is a special kind of function that can be used in a for loop and is defined with generator instead of def. As other people have mentioned, Icon doesn't use special syntax to introduce generators. We might as well look at CLU, too, where a different approach. You can view the CLU Reference Manual at: http://ncstrl.mit.edu/Dienst/UI/2.0/Describe/ncstrl.mit_lcs%2fMIT%2fLCS%2fTR -225 It uses "proc" to introduce a procedure and "iter" to introduce an iterator. See page 72 for the details: http://ncstrl.mit.edu/Dienst/UI/2.0/Page/ncstrl.mit_lcs%2fMIT%2fLCS%2fTR-225 /72 It's a toss up, then between the historical antecedents Icon and CLU. I'd tend to favor a new keyword for generators, but could be talked out of that position. Jeremy