An alternative approach to bound methods

Tim Couper drtimcouper at
Tue Feb 20 10:55:08 EST 2001

Marcin wrote
A disadvantage of current function-to-bound-method
conversion is that it checks the type of the object
and does an adjustment in a specific case, instead of
working uniformly for all types. It breaks when a
method is implemented as some other object than a
function and introduces unnecessary complexity to the
language definition.

Why to have unbound methods as a separate concept from
functions? Why objects of other types can't act as
methods? Why I can store any value as a data of a
class *except* functions (which are converted
to unbound methods)? And I would like to have static

The conversion happens during extraction of an
attribute out of a class, in case it's a function.
IMHO it should happen during translation of
extract-from-instance to extract-from-class, for all

obj.x, when obj is an instance object, first searches
for 'x' in its __dict__. If not found, it should try
obj.__class__.x, converting it to a bound method by
making a proxy object which, when called, calls the
function with obj argument prepended (and perhaps
passes other attribute accesses transparently, but
it's not essential - it could provide the real
function as im_func only as well).

Nothing magical happens when attributes are extracted
from a class itself, no matter what their types are.
There are no unbound methods, just functions. You can
define static methods by plain def m() in a class,
without the self parameter. You can call any method as
a static method, with any object as its first
argument. Only when you call a method through an
instance, self is prepended. Any callable object can
behave as a method.

What we lose is the ability to access class attributes
by getting an attribute of an instance (in case they
are not functions, because you could not do it when
they are functions anyway). It's not a problem except
compatibility. When scopes nest, you can just refer to
these names unqualified. You can also refer to them
qualified by the class name, which works as now from
any place where the class is accessible.

What do you think?


FWIW I think that this seems an excellent suggestion;
for one, I would find it a real asset to have such a
seemingly python-esque way of having class
functions/static methods available in this manner.
What is the procedure to bring this suggestion the the

Tim Couper 

Do You Yahoo!?
Get your free address at
or your free address at

More information about the Python-list mailing list