On Fri, Aug 13, 2010 at 5:54 PM, Greg Ewing email@example.com 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.