[Python-ideas] Yet another alternative name for yield-from

[Guido van Rossum]

On Thu, Apr 2, 2009 at 4:14 PM, Jacob Holm <jh at improva.dk> wrote:
> Nick Coghlan wrote:
>>
>> Using 'yield return' rather than a bare return wouldn't get any
>> objections from me. As has been said before, the current SyntaxError
>> definitely makes it easier to learn some of the ins and outs of
>> generators.
>>
>> That would leave us with:
>>
>> 'yield': pass a value back to and receive a value from this generator's
>> client
>> 'yield from': pass control to a subgenerator and receive a value back
>> from it
>> 'yield return': finish this generator with GeneratorReturn
>> 'return': finish this generator with StopIteration
>>
>
> FWIW, I still don't see the need for a GeneratorReturn exception.  I don't
> understand why it should be an error to ignore the return value, or to loop
> over a generator that returns a value.  I assume it makes sense to someone
> since it is being discussed, so perhaps one of you someones would care to
> explain it?

I've explained this more than once in some of the many yield-from
threads, but since I am myself asking for a summary of previous
threads I'll explain it again.

Generators are a mind-bendingly complex issue and it's easy for
someone who is just starting to write a generator for the first time
to get a detail or two wrong. We intentionally decided to make "return
<value>" invalid syntax in a generator to help those people. Surely it
would have been easier to code if we just ignored the value. But we
went the extra mile to help people negotiate the steep learning curve.
I don't want to lose this.

>> I think that leaves us with one remaining question: should we save the
>> return value on the generator iterator and make it available as the
>> return value of the close() method?
>>
>
> I think so, yes.  It makes a big difference to some of the examples I have
> shown.

I must have missed that.

>> My inclination is that finalising a generator in a way that allows the
>> return value to be retrieved should be left out of the PEP for now, as
>> it is something that can be:
>> a) easily done externally to the generator*
>>
>
> Yes, you can hack your way around most limitations.  In this case if you
> need the feature it makes quite a big difference to both the calling and the
> called code.
>
>> b) added to close() later if we decide it would be a good idea
>>
>
> That is true, but I think the semantics of "yield-from" becomes more
> coherent if we do it now.  Alternatively, we could drop the "yield return"
> idea from the proposal and make "yield from" a statement.  I would hate to
> see it go because coupled with returning the value from close it has some
> really nice uses, but that would be the other way I see to make the proposal
> coherent.   Having "yield return" without returning the value from close
> just feels wrong.
>
>> In order to leave that avenue open in the future however, close() must
>> be defined in the PEP to trap GeneratorReturn as well as StopIteration.
>>
>
> But if we do that without storing the value and returning it on the next
> close, you cannot use "yield return" as a response to GeneratorExit in a
> subiterator without losing the returned value.  (This of course depends on
> how we end up handling GeneratorExit and close in the yield-from
> expression).  Instead you will need to manually raise a different exception
> in the subiterator.  And if you do that, the resulting generator can no
> longer be closed *without* some wrapper to catch the exception.
>
>
>> So +1 to having close() accept GeneratorReturn as a legitimate reaction
>> to being thrown GeneratorExit, but -0 on saving the return value on the
>> generator iterator object (at least in the initial version of the PEP)
>>
>>
>
> And I am +1/+1 on this, although I would rather see the "yield return"
> statement just storing the value directly on the generator, raising a normal
> StopIteration, and not using a GeneratorReturn exception at all.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)