Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should http.client.HTTPMessage be subtype of Mapping[str, str]? #5729

Closed
Unrud opened this issue Jul 5, 2021 · 3 comments
Closed

Should http.client.HTTPMessage be subtype of Mapping[str, str]? #5729

Unrud opened this issue Jul 5, 2021 · 3 comments

Comments

@Unrud
Copy link
Contributor

Unrud commented Jul 5, 2021

Example:

URLopener.http_error has the argument headers: Mapping[str, str]. It gets called with the value of HTTPResponse.msg which has the type HTTPMessage.

@srittau
Copy link
Collaborator

srittau commented Jul 5, 2021

Since HTTPMessage does not derive from Mapping at runtime and is also not registered as implementing Mapping, it shouldn't be one in stubs either. See some related discussion in #3576. In my opinion, the correct fix is to add a MappingLike protocol to _typeshed and use that for the headers argument.

@Akuli
Copy link
Collaborator

Akuli commented Jul 5, 2021

I don't think MappingLike should go to _typeshed, because the meaning of "mapping-like" depends on the code that uses it. For example, it could mean "has .items() method", "gives keys when iterating and values from .__getitem__()", or "has .keys() and .__getitem__(). A single protocol can't cover it all. We already have SupportsItems, SupportsKeysAndGetItem and a couple other classes, so we should just use those.

@Unrud
Copy link
Contributor Author

Unrud commented Mar 22, 2022

Fixed in 9bba8a4

@Unrud Unrud closed this as completed Mar 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants