> John J Lee <jjlee@users.sourceforge.net> added the comment:
> 
> * The patch looks like it will break code that uses .header_items(),
> which is not acceptable.

Nope, it does not break. If the concern was subclassing dict may have adverse
effect on .copy and .update methods, thats taken care because the subclass just passes it to the original dict method, which would behave the same way.

    >>> r.header_items()
    [('Spam-Eggs', 'blah')]
    >>> r.add_header("Foo-Bar", "baz")
    >>> items = r.header_items()
    >>> items.sort()
    >>> items
    [('Foo-Bar', 'baz'), ('Spam-Eggs', 'blah')]

> * The patch to the docs seems to muddy the waters even further (than the
> current slightly murky state) about whether and why .headers is to be
> preferred over the methods, or vice-versa.  I think .headers should
> remain undocumented, for the reason stated by the doctest that failed
> with Hans-Peter's original patch.

IIRC, Hans-Peter's comment was on the reference to .headers undocumented interface mentioned in the test_urllib2.

>  The best course of action is
> debatable, but the patch is a regression in this respect, so should not
> be committed as-is.

My understanding in this case was to address 1) Title()-ize the headers and 2)
provide a case insensitive lookup.

Is this sufficient now to expose the headers method? If not, what else?
If headers method should not be exposed, then will the 2 cases addressed above
still do, as this issue request was opened for that?