At 12:36 PM 10/5/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > [...] > > Yep, but another argument in favor of getting rid of as much > > statefulness from the protocol as we can. Making the status and headers > > part of the return value entirely eliminates the question of when > > they're going to get written, and whether they can be changed. > > > > (As a side benefit, making the return a 3-tuple makes it impossible to > > write a WSGI app using a single generator -- thereby discouraging people > > from using 'yield' like it was a CGI "print".) > > > > >Wait, what do you mean by """As a side benefit, making the return a >3-tuple makes it impossible to write a WSGI app using a single generator"""?
I mean that you can't write a WSGI 2.0 application using a single generator function, because it has to return a tuple, not an iterator. This will discourage people from thinking "yield" is a good way to build up their output, instead of using a StringIO or ''.join() on a list of strings. >And what do you mean by """getting rid of as much >statefulness from the protocol as we can"""? Most of WSGI 1.0's complexity comes from the sequence of operations - when you call start_response(), whether you can call it again, whether iteration is in progress, etc. WSGI 2.0 gives all the sequence control to the caller, so that there is no delicate dance of calls back and forth. This especially simplifies middleware that manipulates the output stream, because it doesn't need to wrap start_response() and write(). _______________________________________________ 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
