Most "active" coroutine library project?

[Jason Tackaberry]

On Fri, 2009-09-25 at 18:36 +0000, Grant Edwards wrote:
> That's not comletely transparently.  The routine fetch_google()
> has to know a priori that s.connect() might want to yield and
> so has to invoke it with a yield statement.

With my implementation, tasks that execute asynchronously (which may be
either threads or coroutines) return a special object called an
InProgress object.  You always yield such calls.

So you're right, it does require knowing a priori what invocations may
return InProgress objects.  But this isn't any extra effort.  It's
difficult to write any non-trivial program without knowing a priori what
callables will return, isn't it?


> Completely transparent would be this:
[...]
>              try:
>                  s.connect('google.com:80')
>              except:

Jean-Paul made the same argument.  In my view, the requirement to yield
s.connect() is a feature, not a bug.  Here, IMO explicit truly is better
than implicit.  I prefer to know at what specific points my routines may
branch off.

And I maintain that requiring yield doesn't make it any less a
coroutine.

Maybe we can call this an aesthetic difference of opinion?


> Again, you have to know ahead of time which functions might
> yeild and which ones don't and call them differently.  That's
> the "hoop".

To the extent it should be considered jumping through hoops to find what
any callable returns, all right.


> > It's true that the yields in fetch_google() aren't yielding control
> > _directly_ to one of the task() coroutines, but it _is_ doing so
> > indirectly, via the coroutine scheduler, which runs inside the main
> > loop.
> 
> True.  But I wouldn't call that transparent.

What I meant by transparent is the fact that yield inside fetch_google()
can "yield to" (indirectly) any active coroutine.  It doesn't (and
can't) know which.  I was responding to your specific claim that: 

> [...] the "mis-feature" in Python co-routines that's being discussed
> is the fact that you can only yeild/resume from the main coroutine
> function.

With my implementation this is only half true.  It's true that for other
active coroutines to be reentered, "main" coroutines (there can be more
than one in kaa) will need to yield, but once control is passed back to
the coroutine scheduler (which is hooked into main loop facility), any
active coroutine may be reentered.

Cheers,
Jason.