> 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.

`.mapping` is not exist between Python 3.0~3.9. And it is not feature that is long awaited by many users.

See https://bugs.python.org/issue40890#msg370841
Raymond said:

  Traditionally, we do expose wrapped objects:  property() exposes fget,  partial() exposes func, bound methods expose __func__, ChainMap() exposes maps, etc.
  Exposing this attribute would help with introspection, making it possible to write efficient functions that operate on dict views.

Type hints is very useful for application code, especially when it is large.
But introspection is very rarely used in such typed code bases. I don't think `.mapping` is useful for many users, like `.fget` of the property.
So adding `# type: ignore` in such lines is the "lesser evil".


> 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.

It doesn't make sense at all, IMO.
If we really need `.mapping` in typeshed, we should add it to `KeysViewWithMapping`.
So mapping classes that don't inherit dict shouldn't be forced to implement `.mapping`.


> 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.

`# type: ignore`.


> 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.

What problem this problem solve? `SortedDict.keys()` can not return `dict_keys`.
As far as I think, your motivation is making dict subclass happy with type checkers.
But this option doesn't make dict subclass happy at all.