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. However, you're talking about the agreed-upon interface between a scheduler and the objects that it schedules. That's a matter for the scheduler author do decide upon and document. It may well be that some schedulers will require some or all of the generator methods to be implemented, but I expect there to be a substantial class that don't. The wording in the PEP is only meant to specify the language-mandated requirements for an object to be used with cocall. If both yield-from and cocall are to exist, it's simplest to use the same semantics for both. Making the language definition any more complicated would require a fairly strong justification, and I'm not convinced that this qualifies. For the convenience of schedulers, functions could be provided for sending, throwing and closing that provide the same fallback behaviour as yield-from and cocall. -- Greg