[Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python (original) (raw)

Guido van Rossum guido at python.org
Thu Sep 18 23:53:15 CEST 2008

On Thu, Sep 18, 2008 at 2:15 PM, Mark Seaborn <mrs at mythic-beasts.com> wrote:

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, > "imself", "imfunc" and some other special cases are treated as > private attributes. In 3.0, unbound methods are gone and imself and imfunc are self and func attributes of method objects. Yes. The renaming of "imself" and "imfunc" 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

I don't know to what extent you want to modify Python fundamentals, but I think this could be solved simply by adding a metaclass that returns an unbound method object for C.f, couldn't it?

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list