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

[Nick Coghlan]

On Sat, Aug 14, 2010 at 11:54 AM, Greg Ewing
<greg.ewing at 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 at gmail.com   |   Brisbane, Australia