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

[Jacob Holm]

Nick Coghlan wrote:
> Jacob Holm wrote:
>   
>> At least part of the confusion comes from the fact that if yield-from
>> could somehow suppress the initial next and yield a different value
>> instead (either an extra expression in yield-from or the last value
>> yielded by a primed generator), there would be a simple way to write
>> wrappers that could be used at the call site to handle all those cases. 
>> So a feature that allowed specifying the first value to yield in the
>> yield-from expression *would* be enough, but a start argument to the
>> coroutine constructor isn't.
>>     
>
> I think leaving this task to wrapper classes in the initial version of
> the PEP is the right way to go at this point. 

I have already given up on getting this feature in at this point.  The 
above paragraph was just meant to clear up some misunderstandings.

> Adding a "skip the initial
> next and yield <expr> instead" clause later will be much easier than
> trying to undo something added now if it turns out to be a mistake.
>   

Note that if we decide that it is OK to use yield-from with an 
already-started generator in this version, we can't later change 
yield-from to use the latest value yielded in place of the initial 
next().  That makes new syntax the only possibility for that future 
extension.  Not that this is necessarily a bad thing.

> Greg's basic proposal makes the easy things easy and the difficult
> things possible, so it is a very good place to start. 

Yes. You can even write the slow version of the call-wrappers I am 
talking about, and then replace them with the faster versions later if 
the feature becomes available.

> The main change I
> would like from the original version of the PEP is for caching the bound
> methods to be explicitly disallowed in order to match the behaviour of
> normal for loops.
>   

I am not really sure about this.  It looks very much like an 
implementation detail to me.  On the other hand, the ability to replace 
the methods mid-flight might give us a way to implement the 
call-wrappers with minimal overhead.  Since the current patches don't 
actually do any caching, this is something I should actually be able to try.


- Jacob