Most "active" coroutine library project?

[exarkun at twistedmatrix.com]

On 09:40 pm, tack at urandom.ca wrote:
>On Wed, 2009-09-23 at 20:50 +0000, exarkun at twistedmatrix.com wrote:
>>immediately outside the generator.  This means that you cannot use
>>"enhanced generators" to implement an API like this one:
>>
>>     def doSomeNetworkStuff():
>>         s = corolib.socket()
>>         s.connect(('google.com', 80))
>>         s.sendall('GET / HTTP/1.1\r\nHost: www.google.com\r\n\r\n')
>>         response = s.recv(8192)
>>
>>where connect, sendall, and recv don't actually block the entire 
>>calling
>>thread, they only switch away to another coroutine until the 
>>underlying
>>operation completes.  With "real" coroutines, you can do this.
>
>I might be missing some subtlety of your point, but I've implemented
>this functionality using generators in a library called Kaa[1].  In 
>kaa,
>your example looks like:
>
>        import kaa
>
>        @kaa.coroutine()
>        def do_some_network_stuff():
>           s = kaa.Socket()
>           yield s.connect('google.com:80')
>           yield s.write('GET / HTTP/1.1\nHost: www.google.com\n\n')
>           response = yield s.read()
>
>        do_some_network_stuff()
>        kaa.main.run()

I specifically left out all "yield" statements in my version, since 
that's exactly the point here. :)  With "real" coroutines, they're not 
necessary - coroutine calls look just like any other call.  With 
Python's enhanced generators, they are.

Jean-Paul