An object-capability subset of Python

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

Mark