[Python-ideas] x=(yield from) confusion [was:Yet another alternative name for yield-from]

[Jacob Holm]

Guido van Rossum wrote:
> On Wed, Apr 8, 2009 at 8:04 AM, Jacob Holm <jh at improva.dk> wrote:
>   
>> Jacob Holm wrote:
>>     
>>> Even assuming every relevant object implemented the pattern I suggest, it
>>> is still not possible to use yield-from to write something like
>>> itertools.dropwhile and have it delegate all send and throw calls correctly.
>>> To make that possible, you need exactly the same thing that you need for
>>> pre-started coroutines: The ability to replace the next() call made by the
>>> yield-from expression with something else. Give me that, and you will also
>>> have removed the need for a special pattern for coroutines that should be
>>> usable with yield-from.
>>>       
>> To be clear, I think the best way of handling this is to add a read-only
>> property to generator objects holding the latest value yielded, and let
>> yield-from use that when present instead of calling next(). (This is not a
>> new idea, I am just explaining the consequences as I see them). The property
>> can be cleared when the frame is released, so there should be no issues with
>> that.
>>     
>
> Let me just respond with the recommendation that you stop pushing for
> features that require storing state on the generator object. Quite
> apart from implementation issues (which may well be non-existent) I
> think it's a really scary thing to add any "state" to a generator that
> isn't contained naturally in its stack frame.
>   

Does storing it as part of the frame object count as "naturally in the 
stack frame"?  Because that is probably the most natural place to put 
this, implementation-wise.  If storing on the frame object is also out, 
I will have to start thinking about new syntax again.  Oh well.

I was going to push for saving the final return value from a generator 
somewhere so that each StopIteration raised by an operation on the 
closed generator could have the same value as the StopIteration that 
closed it (or None if it was closed by another exception).  If that 
value can't live on the generator object, I guess that idea is dead.  Am 
I right?

> If this means that you can't use yield-from for some of your use
> cases, well, so be it. It has plenty of other use cases.
>   

That is exactly what I am worried about.  I think the number of use 
cases will be severely limited if we don't have a way to replace the 
initial next() made by yield-from.  This is different from the close() 
issues we debated earlier, where there is a relatively simple 
workaround.  The full workaround for the "initial next()" issue is big, 
ugly, and slow.

Anyway, I still hope the workaround won't be needed.

> And no, I am not prepared to defend this recommendation. But I feel
> very strongly about it. So don't challenge me -- it's just going to be
> a waste of everyone's time to continue this line of thought.
>   

No, I am not going to challenge you on this.   Once I have your answer 
to the questions at the beginning of this mail, I will try to adjust my 
future proposals accordingly.

Best regards
- Jacob