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

[Nick Coghlan]

Guido van Rossum wrote:
> [Guido]
>>> Oh, and "yield from" competes with @couroutine over
>>> when the initial next() call is made, which again suggests the two
>>> styles (yield-from and coroutines) are incompatible.
>>
>> It is a serious problem, because one of the major points of the PEP is
> that
>> it should be useful for refactoring coroutines.  As a matter of fact, I
>> started another thread on this specific issue earlier today which only
> Nick
>> has so far responded to.  I think it is solvable, but requires some more
>> work.
> 
> I think that's the thread where I asked you and Nick to stop making more
> proposals.I a worried that a solution would become too complex, and I
> want to keep the "naive" interpretation of "yield from EXPR" to be as
> close as possible to "for x in EXPR: yield x". I think the @coroutine
> generator (whether built-in or not) or explicit "priming" by a next()
> call is fine.

The trick is that if the definition of "yield from" *includes* the
priming step, then we are saying that coroutines *shouldn't* be primed
in a decorator. I don't actually have a problem with that, so long as we
realise that existing coroutines that are automatically primed when
created won't work unmodified with "yield from" (since they would get
primed twice - once by the wrapper function and once by the "yield from"
expression).

To be honest, I see that "auto-priming" behaviour as similar to merging
creation of threading.Thread instances with calling t.start() on them -
while it is sometimes convenient to do that, making it impossible to
separate the creation from the activation the way a @coroutine decorator
does actually seems like an undesirable thing to do.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------