homepage

urllib2.Request.headers is, in practice, an undocumented public
interface. Did you run the tests? There is room for improvement here,
but not in the way you suggest.
python[1]$ python2.6
iPython 2.6a1+ (trunk:62045M, Mar 30 2008, 03:07:23) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.test_urllib2
>>> print test.test_urllib2.test_request_headers_dict.__doc__
 The Request.headers dictionary is not a documented interface. It should
 stay that way, because the complete set of headers are only accessible
 through the .get_header(), .has_header(), .header_items() interface.
 However, .headers pre-dates those methods, and so real code will be
using
 the dictionary.
 The introduction in 2.4 of those methods was a mistake for the same
reason:
 code that previously saw all (urllib2 user)-provided headers in .headers
 now sees only a subset (and the function interface is ugly and
incomplete).
 A better change would have been to replace .headers dict with a dict
 subclass (or UserDict.DictMixin instance?) that preserved the .headers
 interface and also provided access to the "unredirected" headers. It's
 probably too late to fix that, though.
 Check .capitalize() case normalization:
 >>> url = "http://example.com"
 >>> Request(url, headers={"Spam-eggs": "blah"}).headers["Spam-eggs"]
 'blah'
 >>> Request(url, headers={"spam-EggS": "blah"}).headers["Spam-eggs"]
 'blah'
 Currently, Request(url, "Spam-eggs").headers["Spam-Eggs"] raises
KeyError,
 but that could be changed in future.
 
>>>