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

[Aaron Watters]

--- On Mon, 1/4/10, P.J. Eby <pje at telecommunity.com> wrote:

> From: P.J. Eby <pje at telecommunity.com>
> Subject: Re: [Web-SIG] wsgi write=start_response() and iterable return?
> To: "Aaron Watters" <arw1961 at yahoo.com>, web-sig at python.org
> Date: Monday, January 4, 2010, 4:38 PM
> 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:
> ....
> 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.. 
> :-(

... And I'm not sure that a complicated program might not
do this even it was not intended if it uses both idioms.  In
fact since WHIFF is designed to combine external components
you probably can confuse WHIFF (or other intrastructure tools)
into mixing the modes even if the tool doesn't 
mix modes directly.

I'd like to see the write() callable removed from future
versions of WSGI, and wrappers like the one I referenced could
provide backwards compatibility for old style apps.

  -- Aaron Watters
===
less is more