[Python-ideas] asyncore and stuff

[Yaroslav Fedevych]

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.