[Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python

[Mark Seaborn]

Terry Reedy <tjreedy at udel.edu> wrote:

> Mark Seaborn wrote:

> > Private attributes may only be accessed through "self" variables.
> > "Self" variables are defined as being the first arguments of functions
> > defined inside class definitions, with a few restrictions intended to
> > prevent these functions from escaping without being safely wrapped.
> 
> What about functions defined outside class definitions and then attached 
> as an attribute.  Prevented?

Yes, that is prevented: attribute assignment is only allowed on "self"
variables, so you can't assign to class attributes.  Classes can't be
extended that way.  That should not be a big problem for
expressiveness; defining __getattr__ will still be possible.

CapPython has to prevent attribute assignment by default because
Python allows it on objects by default.

It would be possible to allow attribute assignment by having CapPython
rewrite it to a normal method call whose behaviour classes have to opt
into, rather than opt out of.  Currently CapPython does not do any
rewriting.

> > Private attribute names are those starting with "_".   Additionally,
> > "im_self", "im_func" and some other special cases are treated as
> > private attributes.
> 
> In 3.0, unbound methods are gone and im_self and im_func are __self__ 
> and __func__ attributes of method objects.

Yes.  The renaming of "im_self" and "im_func" is good.  The removal of
unbound methods is a *big* problem [1].

Regards,
Mark

[1] http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html