Sigh, another Async framework.<p>Yes it has nice features such can replace the reactor/hub thing. Has futures/promises/deferreds. That has all been done before in Twisted. Yields are cute and there was monocle, I wouldn't say it exactly took off : <a href="https://github.com/saucelabs/monocle" rel="nofollow">https://github.com/saucelabs/monocle</a><p>Twisted has inlineCallbacks that use yields as well. Just import Twisted into stdlib then and use that.<p>I am surprised that gevent was dismissed. Ok, there is also eventlet, if someone doesn't like gevent. Monkey patching is scary? Is it really _that_ scary? Most sane and portable IO code probably runs on that today. Why? Because there is no need to create a parallel world of libraries. Write a test does it pass? Does it handle your use case? I'll take not knowing if my green threads switch tasks and add another green thread lock, instead of doubling my code size with yields, callbacks and futures.<p>Let's talk about Twisted (sorry couldn't resist WAT video reference). I remember for years searching for parallel libraries to parse exotic protocols. Regular Python library is there, but no, can't use that, sorry. Gotta go find or write one that returns Deferreds. You add a single Twisted module in your code, good luck! -- it ripples all the way to the top through your API and you are doomed being locked into the Twisted world forever.<p>When gevent and eventlet came around it was like a breath of fresh air. This is what sane concurrent IO looks like in Python:<p><a href="http://eventlet.net/doc/examples.html" rel="nofollow">http://eventlet.net/doc/examples.html</a><p>My fear is that many will just say fuck it, I'll just use Go/Rust/Erlang for IO bound concurrent problems.<p>It is nice having a benevolent dictator, except when he goes a little crazy, then dictatorship doesn't sounds so much fun anymore.
Perhaps the video makes more clear the rationale. E.g.<p><pre><code> Possible solution: "Standardizing gevent solves all its problems".
One of the responses: "I like to write clean code from scratch".
Another: "I really like clean interfaces".
</code></pre>
So I'd prefer that the BDFL work with the gevent folks to get it cleaned up and integrated while adjusting it to expose a "clean interface".<p>Perhaps the whole thing will make more sense once Guido provides more detail, but I'm underwhelmed and confused.
As Guido mentions, @coroutine/yield from is very similar to C#'s async implementation (with some differences like type safety).<p>Since Guido has the barest of descriptions on how this works, you may find the C# async description useful. [1]<p>[1] <a href="http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...</a>
A minor gripe (seperate from all my other gripes, which other people have already talked about):<p>"...run code in another thread - sometimes there is no alternative - eg. getaddrinfo(), database connections"<p>Just thought I'd mention that async-supporting DNS libs do exist (eg. gevent ships with C-ares), and in particular I've used async postgres database connections in both C and gevent. The code to gevent-ise psycopg2 connections is about 10 or 15 lines, iirc.
Reading that presentation, it seems that Python has way too many Asyncronous I/O libraries/frameworks on its hands (not to be inflammatory though, I see it as a chance).<p>I really wonder why that is not the case in Ruby. I mean there are some, but there's mostly confidential and there doesn't seem to be much interest around them. Especially not to the point that the project leader would take a stab at it.<p>Good on Python anyway, competition is good.
I think it's a great idea. I haven't tried Twisted and having to install some 3rd party component to get it working doesn't sound tempting, however being supported by default, does.
Why does Guido think this is general purpose enough to add to Python but that the scientific features to make it competitive with R aren't? Is he envious of node.js?