[Web-SIG] PEP 444 / WSGI 2 Async

[Antoine Pitrou]

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. The response body is an arbitrary iterable, which means it can be a
sequence, a generator, or something else. WSGI doesn't mandate any specific
feature of generators, such as coroutine-like semantics, and the server doesn't
have to know about them.

> Everyone has their own idea of what a "deferred" is, and there is only 
> one definition of a "future", which (in a broad sense) is the same as 
> the general idea of a "deferred".

A Twisted deferred is as well defined as a Python stdlib future; actually,
deferreds have been in use by the Python community for much, much longer than
futures. But that's besides the point, since I'm proposing that your spec
doesn't rely on a high-level abstraction at all.

> Ratification of PEP 444 is a long way off itself.

Right, that's why I was suggesting you drop your concern for Python 2
compatibility.


Antoine.