Re: An object-capability subset of Python

On Mon, Aug 11, 2008 at 9:31 PM, Mark Seaborn <mrs-ChQETwBkFSdCgCasaBwmdgC/[email protected]> wrote:
> I have been investigating the feasibility of creating an
> object-capability subset of Python, along the lines of Caja and Joe-E.
> I will call the subset CapPython for now, because the name doesn't
> seem to have been taken yet. :-)
>
> Although Python does not provide encapsulation, there is a widely-used
> naming convention for private attributes of objects: their names start
> with an underscore.  CapPython proposes to enforce this convention by
> only allowing private attributes to be accessed through the "self"
> variable that is bound inside methods.  There are more details here:
> http://lackingrhoticity.blogspot.com/2008/08/introducing-cappython.html
> along with some less readable notes here:
> http://plash.beasts.org/wiki/CapPython

I tried to do this years ago. It wasn't well received by the Python
developers :-)

> I have made a start on writing a verifier for CapPython.  The code is
> available from a Bazaar repository on Launchpad:
> https://code.launchpad.net/cappython
>
> So far this is more of a "capability lint" for Python than a real
> verifier; the subset it checks for is not yet safe.  There is a
> loophole that allows method functions to escape (which can violate
> encapsulation).  It does not restrict access to builtin functions
> (getattr, open, etc.).  It does not deal with Python's module system
> at all.  There is quite a harsh restriction on assigning to
> attributes, which can only be done through "self", and as a result of
> this and other restrictions, the verifier does not pass its own
> checks.
>
> I suspect that for this to become more useful it would need to become
> a rewriter rather than a verifier.

Yes, I think you need to take a CaPerl-like approach (and the name
should be CaPython :-).

>  Python's variable binding
> semantics are quite complex, so there would be loopholes if the
> verifier's interpretation of the program did not match Python's
> interpretation.  A rewriter can perform variable renaming which could
> give us more confidence in the result.

Not sure that mere renaming is going to suffice. In CaPerl I did
run-time checking.