Most "active" coroutine library project?

exarkun at exarkun at
Wed Sep 23 23:53:47 CEST 2009

On 09:40 pm, tack at wrote:
>On Wed, 2009-09-23 at 20:50 +0000, exarkun at 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(('', 80))
>>         s.sendall('GET / HTTP/1.1\r\nHost:\r\n\r\n')
>>         response = s.recv(8192)
>>where connect, sendall, and recv don't actually block the entire 
>>thread, they only switch away to another coroutine until the 
>>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 
>your example looks like:
>        import kaa
>        @kaa.coroutine()
>        def do_some_network_stuff():
>           s = kaa.Socket()
>           yield s.connect('')
>           yield s.write('GET / HTTP/1.1\nHost:\n\n')
>           response = yield
>        do_some_network_stuff()

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.


More information about the Python-list mailing list