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
_______________________________________________
Python-ideas mailing list
Python...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
On Feb 20, 2009, at 5:15 PM, Greg Ewing <greg....@canterbury.ac.nz>
wrote:
--Guido
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
-bruce frederiksen
Greg Ewing wrote:
> 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.
>
_______________________________________________
"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:
> 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.
>
_______________________________________________
It's remarked upon as an unresolved issue in the PEP
right now. I'll change it to specify an exception if
you think that's the right thing to do.
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
-bruce frederiksen
Agreed after all.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
A generator containing a yield-from expression is still a generator though.
> 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.
To my eyes, this means that there is an inconsistency between this PEP
and PEP 342.
> 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.
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
> 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().
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