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

2010-01-05 Thread Aaron Watters


--- On Mon, 1/4/10, P.J. Eby p...@telecommunity.com wrote:

 From: P.J. Eby p...@telecommunity.com
 Subject: Re: [Web-SIG] wsgi write=start_response() and iterable return?
 To: Aaron Watters arw1...@yahoo.com, web-sig@python.org
 Date: Monday, January 4, 2010, 4:38 PM
 At 08:42 AM 1/4/2010 -0800, Aaron
 Watters wrote:
 
   From: Aaron Watters arw1...@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

___
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


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

2010-01-04 Thread Aaron Watters

 From: Aaron Watters arw1...@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.

Thanks in advance,
   -- Aaron Watters

===
less is more
___
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


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

2010-01-04 Thread P.J. Eby

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


 From: Aaron Watters arw1...@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..  :-(


___
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