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

[Ian Bicking]

Phillip J. Eby wrote:
>> 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.)

Map (and list comprehensions) imply you are doing something with the 
results, but you aren't, you just want to throw the results away.

>>> 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.

Oh, now I'm confused.  By push I just meant where the application pushes 
data to the server (the write callable) vs. the case where the server 
pulls from the application (the iterable).

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org