So Guido told it's better to discuss things here. Mostly reiterating what I said in the G+ thread. I'm by no means a greybeard in library/language design, and have no successful async project behind me, so please take what I'm saying with a grain of salt. I just want to highlight a point I feel is very important. There should be standard library, but no standard framework. Please. You see, there is a number of event-driven frameworks, and they all suck. Sorry for being blunt, but each one of them is more or less voluntarily described as being almost the ultimate silver bullet, or even a silver grenade, the One Framework to rule them all. The truth is that every framework that prospers today was started as a scratch to a specific itch, and it might be a perfect scratch for that class of itches. I know of no application framework designed as being the ultimate scratch for every itch that is not dead and forgotten, or described on a resource other than thedailywtf. There is a reason for this state of things, mainly that the real world is a rather complex pile of crap, and there is no nice uniform model into which you can fit all of that crap and expect the model still to be good for any practical use. Thus in the world of software, which is notoriously complex subset of the crap the real world is, we are going to live with dozens of event models, asynchronous I/O models, gobs of event loops. Every one of them (even WaitForMultipleObjects() kind of loop) is a priceless tool for a specific class of problem it's designed to solve, so it won't go away, ever. The standard library, on the other hand, IS the ultimate tool. It is the way things should work. The people look at it as the reference, the code written the way it should be, encompassing the best of the best practices out there. Everyone keeps telling, just look at how this thing is implemented. Look, it's in the stdlib, don't reinvent the wheel. It illustrates the Right Way to use the language and the runtime, the ultimate argument to end doubts. In my opinion, the reason a standard library can be regarded this high is exactly because it provides high-quality examples (or at least it should do that), materials, bits and tools, but does not limit you in the way those tools can be used, and does not impose its rules on you if you want to actually roll something of your own. No framework in the world should have this power, as it would defeat the very reason frameworks do exist. And that's why I think, while asyncore and other expired batteries need to be cleaned up and upgraded (so they are of any use), I expect that no existing frameworks would enter the stdlib as de jure standard. I would expect instead that there would be useful primitives each of these frameworks implements anyway, and make the standard networking modules aware of those. But please, no bringing $MYFAVORITEFRAMEWORK into stdlib. You will either end up with something horrendous to support every existing mainloop implemetation out there, unwieldy and buggy, or you will make a clean, elegant framework that won't solve anyone's problem, will be incompatible with the rest of the world and fall into disuse. Or you can bring some gevent, or Tornado, you name it, into stdlib, and make the users of the remaining dozens of frameworks feel like damned outcasts. I feel the same about web things. Picking the tools to parse HTTP requests and forming the responses is okay, as HTTP is not a simple thing; bringing into the standard library the templating engine, routing engine, or, God forbid, an ORM, would be totally insane.