> Victor's use case is unique in that he needs the type
> to be implemented in C.

mxProxy, zope.proxy and zope.security implement object proxies in C (for security purpose). These proxies are not specific to dict, but are generic.

dictproxy is already used in Python by the type.__dict__ descriptor getter of new-style classes since Python 2.2, since this changeset:

changeset:   18933:09df3254b49d
branch:      legacy-trunk
user:        Tim Peters <tim.peters@gmail.com>
date:        Thu Aug 02 04:15:00 2001 +0000
files:       Include/Python.h Include/abstract.h Include/ceval.h Include/classobject.h Include/descrobject.h Include/dictobject.h Include/eval.h Include/func
description:
Merge of descr-branch back into trunk.

Guido van Rossum wrote in its rejection notice of the PEP 416: "On the other hand, exposing the existing read-only dict proxy as a built-in type sounds good to me. (It would need to be changed to allow calling the constructor.) GvR."

--

> To that end, it would be okay to expose _dictproxy
> but not to make it a documented type.

My sandbox only needs the issue #14385, pysandbox can implement its own dictproxy class.

If the issue #14385 is accepted, pysandbox can use any mapping, even a mapping implemented in Python! It's just simpler to implement a secure proxy in C.

So this issue is not directly related to sandboxing.