Dict views wrap an underlying mapping but don't expose that mapping as an attribute. 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.

I'd be happy to write a PR. Method names could be "mapping", "target", "target_mapping", "target_dict", "referent_dict", etc. I like the choice of "target_mapping": d = dict() assert d is d.keys().target_mapping assert d is d.values().target_mapping assert d is d.items().target_mapping

Just "mapping" would suffice. That is variable name used in the ABCs, the name defined in the glossary, and the variable name used in ChainMap (in plural form).

I think this will also require typing.MappingProxyType to change a bit, since it would make a proxy's underlying dict accessible: >>> d = dict() >>> proxy = MappingProxyType(d) >>> type(proxy.items()) is type(d.items()) # should be False True >>> proxy.items().mapping is d # should be False ???

Indeed, with PR 20691 applied, the following crashes: >>> vars(str).items().mapping.clear() >>> "uh oh"

Would the best way to address this be adding new KeysProxy, ValuesProxy, and ItemsProxy types?

I am not sure that it is good idea to expose internal details (do you want to expose also internal details of iterators?), but if expose an underlying dict of a dict view, I think it should be either a copy or a read-only proxy. It should be enough to help with introspection, but will not open the hole in integrity.

> Would the best way to address this be adding new KeysProxy, ValuesProxy, and ItemsProxy types? I feel it is too much. Until real high need is demonstrated, I don't want to introduce such complexity.

property, partial, bound methods and ChinMap all do something complex with the underlying object. Dict-views are quite simple by comparison, is there an example where this would be helpful and better than just passing directly the mapping object?

Do you see any easy way to have some_mapping_proxy.items().mapping return some_mapping_proxy rather than unmasking the proxied dict?

PR 20749 gives each dict view access to a mappingproxy for the original dict, although I don't know if that defeats the original purpose. It might be hard to sensibly make MappingProxy(d).items() return something other than d.items(), since this is already the behavior for user-defined classes: >>> class A: def __getitem__(self, key): return "value" def items(self): return 17 >>> from types import MappingProxyType >>> MappingProxyType(A()).items() 17

Here's a workaround that's possible with PR 20749 applied: >>> d = {"a":1, "b":2} # fill up the dict... >>> DICT = object() >>> d[DICT] = d >>> items = d.items() >>> del d >>> >>> d = items.mapping[DICT].pop(DICT) >>> d {'a': 1, 'b': 2}

I meant that you can make dict_view.mapping always returning a MappingProxyType.

> I meant that you can make dict_view.mapping always > returning a MappingProxyType. That would be a reasonable constraint.

+1.

Would it be better to have a dictview.mapping() method rather than an attribute, since it constructs a new object of a different type and since that's what keys(), values(), and items() are?

 New changeset 3ee0e48b0376a710c08eec6f30e4181563b192a2 by Dennis Sweeney in branch 'master': bpo-40890: Add `mapping` property to dict views (GH-20749) https://github.com/python/cpython/commit/3ee0e48b0376a710c08eec6f30e4181563b192a2 

There is a tiny portability issue.

 New changeset 10c3b2120afa01b2c310ac50e99d8b98c943b0a2 by Pablo Galindo in branch 'master': bpo-40890: Fix compiler warning in dictobject.c (GH-20876) https://github.com/python/cpython/commit/10c3b2120afa01b2c310ac50e99d8b98c943b0a2