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 <1332718734.86.0.165333843981.issue14386@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
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: <1332718734.86.0.165333843981.issue14386@psf.upfronthosting.co.za>
2012-03-25 23:38:54vstinnerlinkissue14386 messages
2012-03-25 23:38:53vstinnercreate