On Sat, Aug 14, 2010 at 11:54 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
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.
By scheduler, I mean the actual dispatch loop, not just any code that happens to live in the same module or package.
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.
Scheduler authors shouldn't have to pepper their code with conditional checks for send/throw/close support on the coroutines. By allowing things that only implement the iterator API without those three methods to be called "coroutines", you're invalidating that assumption, making schedulers that make it technically incorrect. If a scheduler chooses *not* to rely on PEP 342, that's fine. But with PEP 342 in place, we should respect its definition of the expected coroutine API.
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().
The coroutine API is a superset of the iterator API, but it's still different. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia