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

[Greg Ewing]

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