Just to check if I'm understanding the presentation right, will the implementation involve compiler magic to turn this:
@coroutine
def getresp():
s = socket()
yield from loop.sock_connect(s, host, port)
yield from loop.sock_sendall(s, b'xyzzy')
data = yield from loop.sock_recv(s, 100)
# ...
into this, similar to how C# does it? (let's pretend multi-line lambdas exist for a minute)
def getresp():
s = socket()
loop.sock_connect(s, host, port).add_done_callback(lambda:
loop.sock_sendall(s, b'xyzzy').add_done_callback(lambda:
data = loop.sock_recv(s, 100).add_done_callback(lambda:
# ...
)
)
)
Or will the `yield from`s bubble up all the way to the event loop and avoid the need for that?
It is Eventlet and Gevent have that magic. Here is how that looks:
def getresp():
s = socket()
s.connect((host,port))
s.sendall(s,b'xyzzy')
data = s.recv(s,100)
Compare that to any of the above. This is what is thrown away in favor of 'yield from' and @coroutine mess coupled with a completely parallel set of IO libraries.
Well... There actually are a completely parallel set of IO libraries, it just happens that the interface can be identical to the existing blocking interfaces because of the greenlet stack slicing magic... So it only appears like there are not a completely parallel set of IO libraries.
> So it only appears like there are not a completely parallel set of IO libraries.
Right on. That's the great part -- both a simple way to program and re usability of libraries.
So far, I see library ecosystem fragmentation as the biggest issue of all and nobody seems to want to talk to it.
Academically all the yields and co-routines look so cool, in practice when you need 5 libraries to help with some task, and now you have to re-write them -- not so cool.
I don't understand your question. From the implementation perspective Python doesn't rewrite things to continuation-passing-style but the end result should be the same.
