> I also think that keeping a status quo (ignoring the mapping attribute in typing) is the lesser evil.

Can you clarify this? There are several things that typing could do, and I don't know which option you are referring to. I listed most of them below, and I'd like to know which exactly of them "is the lesser evil".

If we literally ignore the attribute, any usage of `.mapping` will be an error, which basically makes the whole `.mapping` feature useless for statically typed code. It also wouldn't appear in IDE autocompletions.

If we add it to `KeysView` and `ValuesView`, library authors will end up using `.mapping` with arguments annotated as `Mapping` or `MutableMapping`, not realizing it is purely a dict thing, not required from an arbitrary mapping object.

If we keep `.mapping` in dict but not anywhere else, as described already, it becomes difficult to override .keys() and .values() in a dict subclass. You can't just return a KeysView or a ValuesView. If that was allowed, how should people annotate code that uses `.mapping`? You can't annotate with `dict`, because that also allows subclasses of dict, which might not have a `.mapping` attribute.

Yet another option would be to expose `dict_keys` and `dict_values` somewhere where they don't actually exist at runtime. This leads to code like this:


from typing import Any, TYPE_CHECKING
if TYPE_CHECKING:
    # A lie for type checkers to work.
    from something_that_doesnt_exist_at_runtime import dict_keys, dict_values
else:
    # Runtime doesn't check type annotations anyway.
    dict_keys = Any
    dict_values = Any


While this works, it isn't very pretty.