[Web-SIG] PEP 444 / WSGI 2 Async

[Antoine Pitrou]

Alice Bevan–McGregor <alice at ...> writes:
> 
> On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
> > Alice Bevan–McGregor <alice at ...> writes:
> >>> I don't understand why you want a "yield" at this level. IMHO, WSGI 
> >>> needn't involve generators. A higher-level wrapper (framework, 
> >>> middleware, whatever) can wrap fd-waiting in fancy generator stuff if 
> >>> so desired. Or, in some other environments, delegate it to a reactor 
> >>> with callbacks and deferreds. Or whatever else, such as futures.
> >> 
> >> WSGI already involves generators: the response body.
> > 
> > Wrong.
> 
> I'm aware that it can be any form of iterable, [snip]

Ok, so, WSGI doesn't "already involve generators". QED.

> > Right, that's why I was suggesting you drop your concern for Python 2 
> > compatibility.
> 
> -1
> 
> There is practically no reason for doing so;

Of course, there is one: a less complex PEP without any superfluous
compatibility language sprinkled all over. And a second one: a simpler PEP is
probably easier to get contructive comments about, and (perhaps some day)
consensus on.

> esp. considering that I've 
> managed to write a 2k/3k polygot server that is more performant out of 
> the box than any other WSGI HTTP server I've come across and is far 
> simpler in implementation than most of the ones I've come across with 
> roughly equivelant feature sets.

Just because you "managed to write" some piece of code for a *particular* use
case doesn't mean that cross-compatibility is a solved problem. If you think
it's easy, then I'm sure the authors of various 3rd-party libs would welcome
your help achieving it.

> Python 2.x will be around for a long time.

And so will PEP 3333 and even PEP 333. People who value legacy compatibility
will favour these old PEPs over your new one anyway. People who don't will
progressively jump to 3.x.

Antoine.