An alternative approach to bound methods

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Mon Feb 19 19:29:43 CET 2001


Here is how I would handle bound methods. Similar to Python but
a bit different.

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 methods.

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 cases.

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?

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK



More information about the Python-list mailing list