Jim Roskind says you can do it with current constructs:
> class a:
> def m(self): ...
> class b(a):
> def m(self): ... b.__bases__[0].m() ... # Calls a.m()
> class c(b):
> def m(self): ... c.__bases__[0].m() ... # Calls b.m()
Ahum... I think that Craig wanted "parent" to act as a kind of "self"
but with a different class. Jim's solution would have to be written
as
def m(self): ... b.__bases__[0].m(self) ... # Calls a.m()
^^^^
and I don't think it has the sparkling elegance that Craig was looking
for :-)
Unfortunately, 'parent' is impossible to add to Python without
violating some other principles. A method currently has no idea in
which class it is defined: all it knows is the identity of 'self'
(whose class could be any number of derived classes away) and the
current *global* name space, which usually (but not necessarily)
contains the current class as well as its base class. Therefore, to
reference a base class, the only way (apart from Jim's b.__bases__[0])
is to name it explicitly.
Of course, it would be rather silly to have a magic 'parent' in the
language where 'self' has to be mentioned explicitly... Since I'm
convinced that explicit 'self' is a Good Thing (in the context of
Python, anyway), I'm even more convinced that having to name the
parent explicitly is a Good Thing as well.
Craig's reason for wanting 'parent' is that if he chooses a different
base class he doesn't want to have to rename all the calls to base
class methods. However, choosing a different base class is usually a
rather drastic thing -- the new base class might have a different set
of methods. Therefore I think it's good that you are forced to have
at least a quick look at all places where base class methods are
called.
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
<URL:http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>