[Python-ideas] Yield-from: Nonexistent throw() and close()?

[Greg Ewing]

Jacob Holm wrote:
> Hi Bruce
> Bruce Frederiksen wrote:
>> Jacob Holm wrote:
>>
>>> I'd hate for this:
>>>
>>> def foo():
>>>    for i in xrange(5):
>>>        yield i
>>>
>>> to behave different from this:
>>>
>>> def foo():
>>>    yield from xrange(5)
>>
>> These two forms already behave differently when generators are used

Since yield-from doesn't exist yet, there's no 'already
behave'. The issue is whether they *should* behave differently
or not.

The issue can perhaps be brought into better focus by
considering this:

   def dontsendtome():
     y = yield 42
     if y is not None:
       raise AttributeError("dontsendtome has no method 'send'")

Now by the "inlining" interpretation (which I think is very
good and want to keep if at all possible),

   def icantbesenttoeither():
     yield from dontsendtome()

should also raise an AttributeError if you send() it something
that isn't None.

Now, from the outside, there's little observable difference between
a generator such as dontsendtome() and some other iterator that
doesn't have a send() method -- both raise an AttributeError
if you try to send() something other than None. So it's reasonable
to expect them to behave similarly when used in a 'yield from'.

(There is one observable difference, namely that send(None)
to an iterator with no send() raises an AttributeError, whereas it's
impossible to write a generator which can tell the difference.
But I see this as an artifact due to the lack of a send(iter, value)
protocol function, which really ought to exist and translate
send(None) into next() for all iterators).

-- 
Greg