[Web-SIG] Why is response_headers a list instead of a dict?

[Phillip J. Eby]

At 02:51 PM 12/25/2005 -0500, Clark C. Evans wrote:
>On Sun, Dec 25, 2005 at 02:13:00PM -0500, Phillip J. Eby wrote:
>| In any case, the point is moot; this isn't a compatible change to the
>| spec, so it would have to wait for a WSGI 2.0.
>
>In paragraph #3 of the "start_response()" definition, it states that
>type(response_headers) is ListType.  I'm wondering if you'd be willing
>to modify this to isinstance(response_headers, list)?

No.  :)  See below.


>A similar assertion is not made about `environ` parameters, only that
>it is a 'dictionary'.

 From http://www.python.org/peps/pep-0333.html#specification-details :

"""This object must be a builtin Python dictionary (not a subclass, 
UserDict or other dictionary emulation),..."""


>   Could a server or middleware provide a special
>environment handler object (as long as isinstance(environ, dict))?

No; this is explicitly forbidden.  See also Q&A item #1, under:

http://www.python.org/peps/pep-0333.html#questions-and-answers

A different argument applies to the headers list, but it's even worse in 
the headers case.  There is essentially zero probability that a server is 
going to be able to make use of any auxiliary methods of a headers object, 
and it would be crazy for the server to try and introspect to see which of 
the dozens of possible header extensions *might* exist.

The simple solution for code which wants a higher-level interface to either 
environ or headers is to wrap the raw data structures in its own 
enhancements - such as a request and response object.  This is what maybe 
99% of existing applications and frameworks do, so there was no sense in 
duplicating this in WSGI.  Meanwhile, optional features and flexibility are 
things to be *avoided* in a low-level protocol like this, if at all possible.