* Use HTTPMessage for the headers parameter of HTTP event handlers
While the documentation of `BaseHandler.http_error_default()` describes
the `hdrs` (`headers` in most other handlers) as "a mapping object with
the headers of the error", the implementation that is located in
`URLopener._open_generic_http()` will pass `response.msg` instead,
which is of type `http.client.HTTPMessage`.
* Use Message for the headers parameter of HTTPError
When the standard library constructs `HTTPError`, it will
pass an `http.client.HTTPMessage`, which is a subclass of
`email.message.Message`. Picking the superclass for the
annotations gives users the flexibility to for example
the result of the `email.message_from_X()` functions.
The only thing unique to `HTTPMessage` is the undocumented
`getallmatchingheaders()` method, which is only called by
`http.server.CGIHTTPRequestHandler.run_cgi()`. That class
gets its headers from `http.client.parse_headers()` and not
from `HTTPError`, so I think it's safe to use `Message`
as the annotation.
Although the parameter is called 'seq', the implementation shows that it
can be anything that can be passed to map(), which takes iterables:
0f42b726c8/Lib/subprocess.py (L565).
* Annotate three previously missing `MappingProxyType` methods
* `__hash__`
* `__reversed__`
* `__class_getitem__`
* Improve 5 `MappingProxyType` methods
The assumption here is that the underlying mapping is a `dict`,
just is done for `MappingProxyType.copy`
* Make the value type of `types.MappingProxyType` covariant
Several things done:
1. Replace all occurrences of `Any` by respective concrete types.
2. Make `Shelf` and its subclassses generic. (Fixes#5815)
3. `shelve.open` should return a general `Shelf` object, not `DbfilenameShelf`. The documentation does not expose such implementation detail.
4. The argument `dict` is annotated with an abstract type `MutableMapping` rather than concrete type `Dict`.
5. Remove unnecessary methods. Some of them are inherited from `MutableMapping`, so no need to repeat them here.
6. Use builtin-in generics instead of importing from `typing`.
`reversed` is currently annotated as accepting either a `Sequence` or objects implementing the `__reversed__` protocol.
This however is too strict as, per its [docs](https://docs.python.org/3/library/functions.html#reversed), it can take any object that implements `__len__` and `__getitem__`.