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. _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
