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

Phillip J. Eby pje at telecommunity.com
Wed Aug 25 06:41:34 CEST 2004

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.

More information about the Web-SIG mailing list