Author vstinner
Recipients Jim.Jewett, eric.snow, gvanrossum, r.david.murray, rhettinger, vstinner
Date 2012-03-25.23:38:53
SpamBayes Score 3.43723e-09
Marked as misclassified No
Message-id <>
> Victor's use case is unique in that he needs the type
> to be implemented in C.

mxProxy, zope.proxy and 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 <>
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
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.
Date User Action Args
2012-03-25 23:38:54vstinnersetrecipients: + vstinner, gvanrossum, rhettinger, r.david.murray, eric.snow, Jim.Jewett
2012-03-25 23:38:54vstinnersetmessageid: <>
2012-03-25 23:38:54vstinnerlinkissue14386 messages
2012-03-25 23:38:53vstinnercreate