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

Nick Coghlan ncoghlan at gmail.com
Fri Aug 13 14:54:01 CEST 2010


On Fri, Aug 13, 2010 at 5:54 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>
>> I think the cofunction discussion suggests that there are some very
>> different possible answers as to what is the scheduler's
>> responsibility and what is the responsibility of the individual
>> coroutines. Picking one of them as a winner by blessing it with syntax
>> seems rather premature.
>
> I don't follow. How does the syntax I've suggested
> have any bearing on what is the responsibility of the
> scheduler?
>
> As far as I can see, it stays out of the way and lets
> the scheduler and coroutines thrash out whatever
> agreement they want between them.

A PEP 342 based scheduler requires coroutines that implement the
generator API (i.e. ones that support send/throw/close) but you're
claiming that it is acceptable to refer to an ordinary iterator as a
coroutine and use other channels (such as module globals) to
communicate requests to the scheduler. That's the only point I'm
objecting to - I want to see the ability to receive values and
exceptions from outside at suspension points as part of any defined
coroutine API. Part of my goal in that is to emphasise that coroutines
are *not* used in the same way as iterators, and hence have a wider
API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



More information about the Python-ideas mailing list