[Web-SIG] wsgi write=start_response() and iterable return?

[P.J. Eby]

At 08:42 AM 1/4/2010 -0800, Aaron Watters wrote:

> > From: Aaron Watters <arw1961 at yahoo.com>
> > ....
> > If an application returns an iterable response and *also*
> > calls the write()... what is supposed to happen?
>
>After carefully considering all the responses on this issue ;c)
>I came up with the following strategy for dealing with calls to
>write() in combination with an iterable response:  see
>
>  http://listtree.appspot.com/listtreeNotes/qFxCJOYB2xkf2vyQS5L$AA
>
>This wrapper implementation diverts calls to write() into the iterable
>response so the rest of the system can ignore the write()
>function().  I'd be very happy if some of you would take a quick
>look and see if this makes sense to you.

Do note that an application which calls write() from an iterator body 
is *not* WSGI compliant, as described under:

   http://www.python.org/dev/peps/pep-0333/#the-write-callable

"""Applications MUST NOT invoke write() from within their return 
iterable, and therefore any strings yielded by the iterable are 
transmitted after all strings passed to write() have been sent to the 
client."""

In practice, however, wsgiref.handlers treats write() and yield as 
interchangeable, and wsgiref.validate doesn't complain if an 
application calls write() from within an iteration..  :-(