[Web-SIG] Re: Latest WSGI Draft (Phillip J. Eby)

[Phillip J. Eby]

At 07:49 PM 8/24/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>     class GzipOutput(object):
>>         pass
>>     def gzip_middleware(application, compress_level=5):
>>         def do_gzip(environ, start_response):
>>             writer = []
>
>Using a list to simulate mutable inner scopes is hardly what I'd consider 
>a Hello World class of example!  While the trick works, it's not something 
>that I would do without a compelling reason; certainly not just to save 
>creating one class.

Hm.  To me the mutable inner scope thingy is more natural.  I'd blame it on 
my Lisp background, except I don't *have* a Lisp background...  :)


>>It may be that the PEP should contain a list of suggested utility 
>>functions, like this one:
>>     def finish_response(write_func,app_return):
>>         if app_return:
>>             try:
>>                 map(write_func,app_return)
>>             finally:
>>                 if hasattr(app_return,'close'):
>>                     app_return.close()
>>Such a routine would come in handy for response-munging middleware.
>
>I believe you also have to close the GzipFile, as it won't flush its final 
>output until that happens.  So the finally block has to include that as 
>well.  That makes finish_response a bit less of a win.  And again, map is 
>clever but something of an abuse of the function, and not appropriate for 
>any example code.

Abuse of the function?  That's what map() is *for*: to apply a function to 
each item in a sequence.  It's more compact and to the point than a list 
comprehension when all you're doing is applying a single function to a 
sequence of single arguments.  Perhaps I should also blame this on my 
imaginary Lisp background, where map is considered a 
primitive.  :)  (Actually, it's my 7 years of Python showing, since 'map()' 
was king before the advent of listcomps.)


>>For the given application, it's not important.  Gzipping a server push 
>>stream probably doesn't make a lot of sense.  :)
>
>How so?

Don't the subsequent responses have their own headers and transfer 
encodings?  (By server push I mean a multipart response, which is also the 
main scenario for calling write() more than once or yielding more than one 
value and wanting the data to be immediately flushed.