Re: An object-capability subset of Python

Mark Seaborn wrote:
> zooko <[email protected]> wrote:
> 
>> In contrast Guido van Rossum, when I spoke to him at the most recent
>> PyCon, emphatically told me "If you think that Python can be made
>> into a capability system then you do NOT understand Python!".
>> Shortly thereafter he ended our conversation in order to be
>> interviewed by a journalist.
> 
> Unfortunately that attitude can become self-fulfilling.
> 
> I discovered last week that there is a change in Python 3.0 that makes
> it harder to make Python safe.
> 
> Python 3.0 is removing unbound methods from the language.  In Python
> 2.x, if you retrieve a function from an attribute of a class, it gets
> wrapped by a "unbound method" object which adds a type check.
> Currently CapPython depends on this type check being added.
> 
> Suppose there are two unrelated classes:
> 
> class C(object):
>     def __init__(self):
>         self._field = "secret"
> 
> class D(object):
>     def method(self):
>         return self._field
> 
> If you try to use D.method (an unbound method) on an instance of C it
> raises a TypeError:
> 
>>>> c = C()
>>>> D.method(c)
> TypeError: unbound method method() must be called with D instance as first argument (got C instance instead)
> 
> In Python 3.0 this would return "secret" instead of raising TypeError.

That's shocking. They are *deliberately introducing* exactly the
problem that JavaScript has that makes it so difficult to create
secure subsets of JavaScript.

-- 
David-Sarah Hopwood