Home Original page

[Python-ideas] Cofunctions - Getting away from the iterator protocol

Ron Adam ron3200 at gmail.com
Tue Nov 8 06:30:53 CET 2011 
On Sun, 2011-11-06 at 22:21 +1000, Nick Coghlan wrote:
> On Sun, Nov 6, 2011 at 5:20 PM, Ron Adam <ron3200 at gmail.com> wrote:
> > What is needed is a different path out (and back) to the coroutine that
> > doesn't interfere with the standard yield behavior.  Or as you describe
> > it here.
> 
> Did my post of the thread+queue based implementation of a coroutine
> API design concept not go through? It demonstrated exactly the need
> for a separate I/O channel independent of the call/return and
> next/send/throw/yield channels.

I'm looking at it now.  BTW the resume method is missing the 'return
data' at the end.

Yes, I think it will be useful as a way to figure out the best API.

It looks like the API is almost the same as the generator interface,
with different spellings.

What do you think about an inverted generator API?

You almost have that, but the throw is in the thread object, and not
reachable from the thread.

Generator API.

   Outside generator   <-->   Inside generator

      next()                     yield
      .send()
      .throw()


Inverted generator API

   Outside cothread    <-->   Inside cothread

      .resume()                  suspend()
                                 throw() 

Where resume works like yield, (yield to cothread), and suspend() works
like .send().  Throw() raises an exception at the resume() call,
like .throw() raises an exception at the yield in a generator.

Cheers,
   Ron
More information about the Python-ideas mailing list