On Mon, Aug 16, 2010 at 8:46 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Nick Coghlan wrote:
Scheduler authors shouldn't have to pepper their code with conditional checks for send/throw/close support on the coroutines.
Okay, I see what you're getting at now. We've been talking about slightly different things. I've been talking about the semantics of cocall, which, if defined in terms of yield-from without further qualification, inherits its fallback behaviour in the absence of a full set of generator methods.
Ah, OK. To avoid anyone else being tempted to overspecify, perhaps a comment in parentheses to point out that some coroutine schedulers may require a broader coroutine API, such as that of PEP 342? I don't think this is really common enough to justify yet more functions. Although, if you added a coroutines module, you could put costart and those helper functions in there rather than making them builtins. Such a module would also make sense for the decorator/function based alternative proposal. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia