Alternative name for yield-from
I've had another idea about what to call yield-from: y = pass g(x) which means "run this generator, passing through any sent/yielded values etc." It's short, it's suggestive, it doesn't use any new keywords, and there's no danger of confusing it with 'yield'. Now, you're probably reaching for the -1 button at this point, thinking "WTF? That's completely different from the existing meaning of pass!" But there's a sense in which the existing 'pass' can be seen as a degenerate case. Consider the generator def nada(): if False: yield Since it never yields anything, doing pass nada() is effectively a no-op. Thus, 'pass' with no generator at all is a no-op as well. There's still one remaining difference -- the presence of 'pass' with a value would make the containing function into a generator, whereas plain 'pass' wouldn't. We'd just have to live with that inconsistency. -- Greg
On Wed, Feb 18, 2009 at 12:22 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
-1000 because of that last one. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Greg Ewing wrote:
I've had another idea about what to call yield-from:
y = pass g(x)
Is y a list of values sent to g? Excuse me if I'm a bit lost there. I haven't played around with the new generator features yet. I'm thinking if a in "a = yield expr" is the value sent in, and 'y = pass g(x)' iterates all of g, before continueing, then y would have all of the values sent to generator g. Or would it be the last value send to g or the value returned from g?
How about something like this instead: yield expr for next_val from g(X) Where next_value comes from g(), and expr is the value yielded out. Having it resemble a generator expression, makes it clearer it iterates until complete. The idea of generators working as simple threads is cool, but my mental picture of that has probably been a bit unrealistically simple. But I'm still hopeful for a simple way to do it. My wish is to be able to define a generator, and use a decorator or some syntax at define time to make it run in such a way as to buffer at least one value. That is it runs (in the back ground) until it reaches a yield statement instead of waiting for the .next() method to be called and running to the next yield statement. One thing that always bothered me with generator functions is that they are not explicitly defined. Having the presence of yield to determine if they are a generator or not, seems a bit implicit to me. I'd much prefer a new keyword, 'defgen' or something like it instead of reusing 'def'. To me, generators are different enough from functions to merit their own defining keyword. Or maybe it's better to define them as an object to start with? class mygen(generator): ... class mygen(threaded_generator): ... I would be +1 for an objective way to define generators. (Is there a way to do that already?) Cheers, Ron
Ron Adam wrote:
Is y a list of values sent to g? Excuse me if I'm a bit lost there. I haven't played around with the new generator features yet.
This relates to the discussion about my proposal for a 'yield from' statement. Part of it is that 'return x' in a generator will be equivalent to 'raise StopIteration(x)', with x becoming the value of the 'yield from' expression (or in this case the 'pass' expression).
That argument was debated at great length and lost long ago, when generators were first invented. I don't think there's any chance of it being changed now. I don't know that it would help anything much anyhow, since you also need to be aware that it's a generator every time you use it, and even if it's defined differently, that doesn't help at the call site. The only solution to that is naming conventions and/or documentation. -- Greg
On Wed, Feb 18, 2009 at 12:22 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
-1000 because of that last one. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Greg Ewing wrote:
I've had another idea about what to call yield-from:
y = pass g(x)
Is y a list of values sent to g? Excuse me if I'm a bit lost there. I haven't played around with the new generator features yet. I'm thinking if a in "a = yield expr" is the value sent in, and 'y = pass g(x)' iterates all of g, before continueing, then y would have all of the values sent to generator g. Or would it be the last value send to g or the value returned from g?
How about something like this instead: yield expr for next_val from g(X) Where next_value comes from g(), and expr is the value yielded out. Having it resemble a generator expression, makes it clearer it iterates until complete. The idea of generators working as simple threads is cool, but my mental picture of that has probably been a bit unrealistically simple. But I'm still hopeful for a simple way to do it. My wish is to be able to define a generator, and use a decorator or some syntax at define time to make it run in such a way as to buffer at least one value. That is it runs (in the back ground) until it reaches a yield statement instead of waiting for the .next() method to be called and running to the next yield statement. One thing that always bothered me with generator functions is that they are not explicitly defined. Having the presence of yield to determine if they are a generator or not, seems a bit implicit to me. I'd much prefer a new keyword, 'defgen' or something like it instead of reusing 'def'. To me, generators are different enough from functions to merit their own defining keyword. Or maybe it's better to define them as an object to start with? class mygen(generator): ... class mygen(threaded_generator): ... I would be +1 for an objective way to define generators. (Is there a way to do that already?) Cheers, Ron
Ron Adam wrote:
Is y a list of values sent to g? Excuse me if I'm a bit lost there. I haven't played around with the new generator features yet.
This relates to the discussion about my proposal for a 'yield from' statement. Part of it is that 'return x' in a generator will be equivalent to 'raise StopIteration(x)', with x becoming the value of the 'yield from' expression (or in this case the 'pass' expression).
That argument was debated at great length and lost long ago, when generators were first invented. I don't think there's any chance of it being changed now. I don't know that it would help anything much anyhow, since you also need to be aware that it's a generator every time you use it, and even if it's defined differently, that doesn't help at the call site. The only solution to that is naming conventions and/or documentation. -- Greg
participants (3)
-
Greg Ewing -
Guido van Rossum -
Ron Adam