Re: An object-capability subset of Python

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.

This could be worked around using rewriting but it would make
CapPython more complex and it would be harder to have
CapPython-verified and non-CapPython-verified code interact securely.
I've put some more background on this blog post:
http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html

Mark