[Web-SIG] WSGI in standard library
ianb at colorstudy.com
Wed Feb 15 21:52:15 CET 2006
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
More information about the Web-SIG