[Python-ideas] x=(yield from) confusion [was:Yet another alternative name for yield-from]
jh at improva.dk
Sat Apr 11 14:03:39 CEST 2009
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.
More information about the Python-ideas