> (We don't use "view" much but the place where we do use
> it, for keys/values/items views, is very different I think.)

You are right, it's closer to a proxy because it has the same methods than a mapping (except of some methods used to modify a mapping), whereas the API of keys/values/items views is very different from the mapping API.

> Also collections.abc already defines MappingView as the base
> class for KeysView and friends.)

MappingView is a strange ABC: it should probably declare __contains__ as an abstract method. I don't see why it doesn't inherit from Set (which would avoid the need of declaring __contains__, Set is a Container) whereas KeysView, ItemsView and ValuesView do inherit from Set.

I suppose that MappingView is also present to factorize code but it should not be used directly.

Anyway, you are not the first one who remarks that we already use "view" to define something else, so I wrote a new patch to use the "mappingproxy" name (exposed as types.MappingProxyType).

> Also make sure there's no way for someone who has access
> to the proxy to get to the underlying mapping;

I don't think that we can write unit tests for such property. I suppose that the comment below is enough.

> You might even add a comment ...

Done in my last patch:

/* WARNING: mappingproxy methods must not give access to the underlying mapping */