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

[Guido van Rossum]

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()))().

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)