On Fri, Feb 6, 2009 at 3:20 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Stephen J. Turnbull wrote:
Greg Ewing writes:
The fact that yielding is going on is not of interest in that situation
But doesn't "yield" in the sense of "yield the right of way" mean exactly that?
I've no problem with using 'yield' when actually giving up control. But the code making the call doesn't think of itself as yielding. The called code may want to yield, but the caller doesn't care about that. It just wants to make the callee do its thing, whatever it is.
Ideally the caller would be able to use a normal function call, but Python generators don't work that way. The next best thing is a slightly different form of call syntax.
The more I read your motivation the less comfortable I am with using "call" for this purpose. It differs in so many details from a regular call that you're doing your potential users a terrible disservice by trying to pretend that it is something which it isn't, or that it isn't something which it is. Those differences may not seem relevant when sketching a solution, but they come back to haunt you when debugging, for example. It would be way too confusing to have "a different form of call" with totally different semantics that nevertheless used the same *terminology* as is used for regular calls. Imagine the confusion happens when a newbie (maybe someone coming from Fortran :-) writes "call foo(x)" instead of just "foo(x)" and their program totally breaks. "But you told me to call foo" will be their rightful excuse. You could go on, but so could I. A -1 it is. -- --Guido van Rossum (home page: http://www.python.org/~guido/)