Change the type of extension from Mapping to MutableMapping.

[karpetrosyan]

I'm working on a library that implements HTTP Caching for httpx and httpcore (it provides transports and connection pools), and I'd like to add an extension that simply indicates whether or not the response was taken from the cache.

Unfortunately, the type of extension is Mapping, so this is an error for mypy.

response = httpx.Response(200)
response.extensions['my_custom_extension'] = 'something'

OUTPUT

error: Unsupported target for indexed assignment ("Mapping[Str, Any]")  [index]

The solution is to simply change the extension type from Mapping to MutableMapping, allowing us to add custom extensions after the response has been created.

See also this pr

[lovelydinosaur]

Given that response (and request) headers are a mutable mapping, it would be API consistent for response (and request) extensions to also be typed as a mutable mapping, yep.

[karpetrosyan]

Should I open an issue or will a pull request suffice?

[lovelydinosaur]

That's a good question.
What's better for the project?...

• We keep consistent, and open issues even for minor API/type fixes.
• We jump straight to PRs.

I'd probably suggest that an issue is still a good step even for minor cases like this, it'll help make sure we're properly describing the desired functional changes that we're making. Really we want to be able to describe the change without reference to a third party pull request. In this case I think an issue describing the API change and noting that it's consistent with how we handle headers is sufficient.

[karpetrosyan]

I completely agree with you, but what should we do in such cases, when we should do the same thing for httpx and httpcore, open an issue only in httpx and reference it from the httpcore pull request? or create two duplicate issues for httpx and httpcore

[lovelydinosaur]

Take things step-by-step.

You've made a case for this in httpx, so let's just have the issue for that and nothing else.

Not a duplicate of this discussion, but... "describe the change without reference to a third party pull request... [explain] the API change and note that it's consistent with how we handle headers".

[lovelydinosaur]

(If we want to be able to do a good job of communicating our intent during large changes, we should maintain good practice in communicating our intent during small changes)