[Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python] (original) (raw)

Brett Cannon brett at python.org
Fri Jul 7 22:55:35 CEST 2006

On 7/7/06, Guido van Rossum <guido at python.org> wrote:

On 7/7/06, Brett Cannon <brett at python.org> wrote: > I guess I am just not seeing where your approach is better than preventing > the constructor in 'file' and having open() return the 'file' object or > proxy object. With your approach 'file' would be flagged, but with the > other you just put the same check in 'file's constructor. With both you > would probably also want open() to be a factory function anyway. So I don't > see where you gain simplicity or more security. It seems like you are > pushing the check into the eval loop, but you still require the flagging of > objects as unsafe. Going with the other two proposals you don't burden the > eval loop with the check but the objects that you would have flagged in the > first place. > > It just seems like we are pushing around the flagging of unsafe stuff and > that doesn't feel like it buys us much. At the risk of repeating someone's point or making no sense (I'm only following this with half an ear) I would like to point out that as long as there's C code involved, we can have the equivalent of private constructors in C++/Java. This means classes that cannot be constructed by calling the class from Python. C code has to use some other API to create an instance, bypassing this check. It seems reasonable to me, even if most popular types can be constructed. There are other types that have this property, e.g. list iterators. Try type(iter(list()))().

Good point. C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack. But if the check is in the C code for the object itself it is much harder to get around.

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060707/fa8a7838/attachment-0001.html

More information about the Python-Dev mailing list