[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    Re: [Python-ideas] Cofunctions/yield from -> fibers
From:       Nick Coghlan <ncoghlan () gmail ! com>
Date:       2010-08-16 9:30:46
Message-ID: AANLkTin58TNfjMdRwqaWPOw4gZ9_onwPeiyWUkQem5kX () mail ! gmail ! com
[Download RAW message or body]

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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas

[prev in list] [next in list] [prev in thread] [next in thread]