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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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
