j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
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. 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.
Greg's basic proposal makes the easy things easy and the difficult things possible, so it is a very good place to start. 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.