[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 7:52 PM, Jacob Holm <jh at improva.dk> wrote:
>   
>> 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.
>>     
>
> No, that's out too. My point is that I don't want to add *any* state
> beyond what the user thinks of as the "normal" state in the frame
> (i.e. local variables, where it is suspended, and the expression stack
> and try-except stack). Nothing else.
>   

That rules out Gregs and my patches as well.  They both need extra state 
on the frame object to be able to implement yield-from in the first place.


>> If storing on the frame object is also out, I will
>> have to start thinking about new syntax again.  Oh well.
>>     
>
> Sorry, no go. New syntax is also out.
>   

In that case, I give up.  There is no possible way to fix the "initial 
next()" issue of yield-from without one or the other.


>> 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?
>>     
>
> Right.
>   

Then let me revisit my earlier statement that when close() catches a 
StopIteration with a non-None value, it should either return it or raise 
an exception.  Since the value is not saved, a second close() will 
neither be able to return it, nor raise a StopIteration with it.  
Therefore I now think that raising a RuntimeError in that case is the 
only right thing to do.


>>> 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.
>>     
>
> It doesn't matter if there is only one use case, as long as it is a
> common one. And we already have that: Greg Ewing's "refactoring".
>   

I remain unconvinced that the "initial next()" issue isn't also a 
problem for that use case, but I am not going to argue about this.


> Remember, Dave Beazley in his coroutine tutorial expresses doubts
> about whether it is really that useful to use generators as
> coroutines.
>
> You are fighting a losing battle here, and it would be better if we
> stopped short of trying to attain perfection, and instead accepted an
> imperfect solution that may be sufficient, or may have to be extended
> in the future. If your hypothetical use cases really become important
> you can write another PEP.
>
>   

Looks to me like the battle is not so much losing as already lost, and 
probably was from the start.  I just wish I had understood that earlier.

One final suggestion I have is to make yield-from raise a RuntimeError 
if used on a generator that already has a frame.  That would a) open 
some optimization possibilities, b) make it clear that the only intended 
use is with a *fresh* generator or a non-generator iterable, and c) 
allow us to change our minds about the initial next() later without 
changing the semantics of working code.

>> 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.
>>     
>
> Not if you give up now.
>   


Well, since I am giving up on fixing the "initial next()" issue in the 
core, the workaround *will* be needed.  Maybe not in the PEP, but 
certainly as a recipe somewhere.  If you don't mind, I will continue the 
discussion about the details of such a workaround that Nick started a 
couple of mails back in this thread.


>>> 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.
>>     
>
> Great.
>   

Frustrated-ly yours
- Jacob