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

[Guido van Rossum]

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,
>> > "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

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/)