j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
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.