[Python-ideas] CapPython's use of unbound methods
mrs at mythic-beasts.com
Thu Mar 12 21:24:10 CET 2009
Guido asked me to explain why the removal of unbound methods in Python
3.0 causes a problem for enforcing encapsulation in CapPython (an
object-capability subset of Python), which I talked about in a blog
post . It also came up on python-dev .
Let me try a slightly different example to answer Guido's immediate
Suppose we have an object x with a private attribute, "_field",
defined by a class Foo:
self._field = "secret"
x = Foo()
Suppose CapPython code is handed x. It should not be able to read
x._field, and the expression x._field will be rejected by CapPython's
However, in Python 3.0, the CapPython code can do this:
C.f(x) # returns "secret"
Whereas in Python 2.x, C.f(x) would raise a TypeError, because C.f is
not being called on an instance of C.
Guido said, "I don't understand where the function object f gets its
The answer is that function definitions directly inside class
statements are treated specially by the verifier.
If you wrote the same function definition at the top level:
return var._field # rejected
the attribute access would be rejected by the verifier, because "var"
is not a self variable, and private attributes may only be accessed
through self variables.
I renamed the variable in the example, but the name of the variable
makes no difference to whether it is considered to be a self variable.
Self variables are defined as follows:
If a function definition "def f(v1, ...)" appears immediately within a
"class" statement, the function's first argument, v1, is a self
variable, provided that:
* the "def" is not preceded by any decorators, and
* "f" is not read anywhere in class scope and is not declared as global.
The reason for these two restrictions is to prevent the function
object from escaping and being used directly.
More information about the Python-ideas