Nick Coghlan wrote:
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.
No, I don't use module globals to communicate requests to the scheduler, I use function calls or coroutine calls. For example, where a PEP 342 coroutine would do something like yield WaitForSocket(sock) I would instead do yield from wait_for_socket(sock) or cocall wait_for_socket(sock) The implementation of wait_for_socket() may make use of module globals internal to the scheduler to keep track of which coroutines are waiting for which sockets, but that's a detail private to the scheduler.
I want to see the ability to receive values and exceptions from outside at suspension points as part of any defined coroutine API.
The *ability* is there by virtue of the fact that they *can* implement those methods if they want. You seem to be going further and insisting that they *must* implement those methods, even if the implementations are empty or trivial. I still can't see how that's a good thing.
Part of my goal in that is to emphasise that coroutines are *not* used in the same way as iterators,
If you really wanted to do that, you would have to give them a different API altogether, such as using resume() instead of next(). -- Greg