Closed progval closed 2 weeks ago
I don't know the right answer to this. Headers
is not technically a MutableMapping
, but it is way more annoying to use with type checkers if it doesn't inherit from MutableMapping
. It mostly behaves like a mapping, and that's what most users expect, but sometimes it behaves like its underlying list, such as __iter__
. When we were using type stubs, the stubs just lied about its inheritance. When we moved off of type stubs, I made it actually inherit. It looks like the default implementation of MutableMapping.update
does if isinstance(other, Mapping)
, so this is now doing the wrong thing.
Headers
doesn't actually satisfy the MutableMapping
interface, so I guess it makes sense to remove it. Technically, passing Headers
to a parameter annotated as MutableMapping
is wrong, since like the issue here the function might try to use the value as a mapping in ways Headers
doesn't satisfy. But at the same time, most places that expect a mapping will still behave correctly, so now your type checker complains about something that looks like a mapping to you, and you either need to ignore it or add an unnecessary dict(headers)
conversion. 🤷♂️ I guess I'll remove that and see if anything else comes up.
or add an unnecessary
dict(headers)
conversion
By the way, I was quite puzzled about that; but it turns out that dict()
actually calls keys()
instead of __iter__()
. Makes me wonder why MutableMapping
doesn't do that too.
This bit of code from
requests
passes an instance of werkzeug'sHeaders
tocollections.abc.MutableMapping.update()
: https://github.com/psf/requests/blob/main/src/requests/adapters.py#L375Essentially, it does something like this:
but it does not work since Werkzeug 3.1.0:
This is because CaseInsensitiveDict calls the
update
method ofcollections.abc.MutableMapping
, which callsiter()
on the header object to get what it assumes is an iterator of keys (but forHeaders
it's an iterator of (key, value) pairs), then callsgetitem
for each "key".Environment: