Alice Bevan–McGregor <al...@...> 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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
