[Python-ideas] Cofunctions/yield from -> fibers

[Greg Ewing]

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