Yield-from: Details to be decided
I've got to the point in the implementation where I need to decide what to do if you send() a value to a generator that's delegating to something that doesn't have a send() method. Possibilities include: * Ignore the value and call next() instead * Raise an exception What do people think? I'm inclined to raise an exception for the time being, since we can always relax it later if we want. Also, doing so is more consistent with the idea of the caller talking directly to the sub-iterator. -- Greg
In general .send() is picky when it knows for sure the value won't be used -- try .send() on a generator suspended before the first time it yields, that raises an exception too. So yes, an exception, please. (Doesn't the PEP specify this? I told you it would be useful to start coding. :-)) --Guido On Fri, Feb 20, 2009 at 2:15 PM, Jesse Noller <jnoller@gmail.com> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Actually, PEP 342 specifies that send(None) is like next(): "Calling send(None) is exactly equivalent to calling a generator's next() method." So to honor this, you would need to have send(None) call next, while send(anything_else) raises an exception... -bruce frederiksen Greg Ewing wrote:
Good point. On Fri, Feb 20, 2009 at 2:46 PM, Bruce Frederiksen <dangyogi@gmail.com> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Bruce Frederiksen wrote:
Hmmm, yes, but... that's talking about what happens when you call send() on a *generator*. But when yield-from is delegating to some iterator that's not a generator, according the current wording in the PEP, things are supposed to behave as though you were talking directly to the iterator. If it doesn't have a send() method, and you tried to call it directly, you would get an exception. We're in unprecedented territory here, and it's hard to tell what will turn out to be the most useful behaviour without more experience. Raising an exception for now seems like the safest thing to do. -- Greg
On Fri, Feb 20, 2009 at 10:09 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Agreed after all. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
2009/2/21 Greg Ewing <greg.ewing@canterbury.ac.nz>:
A generator containing a yield-from expression is still a generator though.
To my eyes, this means that there is an inconsistency between this PEP and PEP 342.
It will mean that you will need to be aware of the implementation of a generator in order to know whether it is OK to use send(None) as an alternative spelling of next(). In some cases it is handy to use send(None) rather than next, and PEP 342 guarantees that it will work on generators. This will break that guarantee. A way to go round this would be to make the objects returned by generator functions containing yield-from expressions something else than generators - maybe 'delegators' ? -- Arnaud
Arnaud Delobelle wrote:
Yes, and I've now decided that send(None) will be converted to next() upon delegation in all cases. I'm no longer going to describe the semantics in terms of "direct communication", since that's not exactly true any more (and probably never really was). -- Greg
In general .send() is picky when it knows for sure the value won't be used -- try .send() on a generator suspended before the first time it yields, that raises an exception too. So yes, an exception, please. (Doesn't the PEP specify this? I told you it would be useful to start coding. :-)) --Guido On Fri, Feb 20, 2009 at 2:15 PM, Jesse Noller <jnoller@gmail.com> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Actually, PEP 342 specifies that send(None) is like next(): "Calling send(None) is exactly equivalent to calling a generator's next() method." So to honor this, you would need to have send(None) call next, while send(anything_else) raises an exception... -bruce frederiksen Greg Ewing wrote:
Good point. On Fri, Feb 20, 2009 at 2:46 PM, Bruce Frederiksen <dangyogi@gmail.com> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Bruce Frederiksen wrote:
Hmmm, yes, but... that's talking about what happens when you call send() on a *generator*. But when yield-from is delegating to some iterator that's not a generator, according the current wording in the PEP, things are supposed to behave as though you were talking directly to the iterator. If it doesn't have a send() method, and you tried to call it directly, you would get an exception. We're in unprecedented territory here, and it's hard to tell what will turn out to be the most useful behaviour without more experience. Raising an exception for now seems like the safest thing to do. -- Greg
On Fri, Feb 20, 2009 at 10:09 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Agreed after all. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
2009/2/21 Greg Ewing <greg.ewing@canterbury.ac.nz>:
A generator containing a yield-from expression is still a generator though.
To my eyes, this means that there is an inconsistency between this PEP and PEP 342.
It will mean that you will need to be aware of the implementation of a generator in order to know whether it is OK to use send(None) as an alternative spelling of next(). In some cases it is handy to use send(None) rather than next, and PEP 342 guarantees that it will work on generators. This will break that guarantee. A way to go round this would be to make the objects returned by generator functions containing yield-from expressions something else than generators - maybe 'delegators' ? -- Arnaud
Arnaud Delobelle wrote:
Yes, and I've now decided that send(None) will be converted to next() upon delegation in all cases. I'm no longer going to describe the semantics in terms of "direct communication", since that's not exactly true any more (and probably never really was). -- Greg
participants (5)
-
Arnaud Delobelle -
Bruce Frederiksen -
Greg Ewing -
Guido van Rossum -
Jesse Noller