[Web-SIG] WSGI in standard library

[Ian Bicking]

Clark C. Evans wrote:
> On Wed, Feb 15, 2006 at 11:27:01AM -0800, Guido van Rossum wrote:
> | > If you're worried about "featurebloat" have you even looked at 
> | > the 190 line headers.py?  I rest my case.
> | 
> | What case? It's totally reasonable code implementing a fairly complete
> | mapping API. Smells similar to rfc822.py actually.
> 
> Then perhaps this should be included in the ``list`` or ``dict``
> interface.  If it is WSGI specific, then it's "feature bloat".  I have a
> very large WSGI application, and I've not seen the need for this module
> even once.  While I don't mind it, it is unnecessary baggage: it is not
> required by the specification and does little to help its usage.

I've used this several times (well, not wsgiref's implementation, but 
paste.response.HeaderDict).  rfc822 is heavier than this dictionary-like 
object, and apparently is also deprecated.  Too bad, the email module is 
much heavier still.

Anyway, I'm +1 on the object going somewhere.  I don't know if the 
parent package has to be named "wsgi" -- and "wsgiref" seems even 
stranger to me, as anything in the standard library isn't a "reference 
implementation" anymore, but an actual implementation.  I personally 
like a package name like "web".  Everyone will know what that means 
(though it would start with most of the web related modules not in it, 
which is a problem).

If it was refactored a little, a similar object could be used for URL 
parameters, which are ordered/multivalue but case sensitive.  Maybe 
something to consider.  OTOH, maybe it should just be a similar object. 
  And maybe both should use UserDict.DictMixin; much simpler then.

Oh, and I don't like that __getitem__() and .get() are the same. 
__getitem__ should raise KeyError.

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