Most "active" coroutine library project?

[exarkun at twistedmatrix.com]

On 10:18 pm, tack at urandom.ca wrote:
>On Wed, 2009-09-23 at 22:07 +0000, exarkun at twistedmatrix.com wrote:
>>Sure, no value judgement intended, except on the practice of taking
>>words with well established meanings and re-using them for something
>>else ;)
>
>I think it's the behaviour that's important, and not the specific 
>syntax
>needed to implement that behaviour.
>
>In other words, I disagree (if this is what you're suggesting) that
>sticking "yield" in front of certain expressions makes it any less a
>coroutine.

Alright, I won't pretend to have any particular insight into what the 
fundamental "coroutineness" of a coroutine is.

To me, the difference I outlined in this thread is important because it 
is a difference that is visible in the API (almost if it were some 
unusual, extra part of the function's signature) to application code. If 
you have a "send" function that is what I have been calling a "real" 
coroutine, that's basically invisible.  Put another way, if you started 
with a normal blocking "send" function, then applications would be using 
it without "yield".  If you used "real" coroutines to make it 
multitasking-friendly, then the same applications that were already 
using it would continue to work (at least, they might).  However, if you 
have something like Python's enhanced generators, then they all break 
very obviously, since "send" no longer returns the number of bytes 
written, but now returns a generator object, something totally 
different.

Now, I would say that this there's not a huge amount of value in being 
able to make a function into a coroutine behind the application's back. 
All kinds of problems can result from this.  Others will certainly 
disagree with me and say that it's worth more than the cost of the 
trouble it might cause.  But either way, there's clearly *some* 
difference between the "real" coroutine way and the enhanced generators 
way.

If you think that's not an important difference, I don't mind.  I just 
hope I've made it clear why I initially said that enhanced generators 
aren't what a lot of people would call coroutines. :)
>
>Now, requiring explicit yields does mean that the coroutine has
>specific, well-defined points of reentry.  But I don't believe it's a
>necessary condition that coroutines allow arbitrary (in the
>non-deterministic sense) reentry points, only multiple.

I don't think "non-deterministic" is the right word to use here; at 
least, it's not what I was trying to convey as possible in coroutines. 
More like "invisible".

That aside, I do think that most people familiar with coroutines from 
outside of Python would disagree with this, but I haven't don't a formal 
survey or anything, so perhaps I'm mistaken.

Jean-Paul