Apart from personal likes and dislikes, I agree that sometimes it is a
nuisance having to spell out the name of the base class (especially if
it happens to have the form VeryLongModuleName.EvenLongerClassName :-).
But this is no more than a nuisance.
However, bringing in multiple inheritance changes the matter. (In
fact, in a totally different context, I remember having implemented
exactly this kind of functionality: "give me the object named X that
would be used if there wasn't an X defined locally".) I would still
maintain that if you don't know which base class's X you are
overriding you are in trouble (i.e. you don't know a basic fact about
the code you are using), but I agree that extending a method deserves
some special facility.
I would like to find a way that doesn't need new syntax. Other
requirements are that it should be reasonably compact to write down,
it shouldn't require you to quote the attribute name, it shouldn't
pollute the instance's name space, nor should it use underscores to
avoid namespace pollution. How about a built-in function "super"
which returns a pseudo object whose name space is that of its argument
except that the derived class is stripped? So you would be able to
write super(self).doit(how). (Adding a new built-in function is also
a form of namespace pollution, but causes fewer conflicts and no
backward compatibility problems since user-defined global and local
names have priority over built-in functions.)
{I now do believe that your implementation of super works.]
> Let me rephrase this: Currently what the repr() prints out is of
> little use to see what it is. It would be *much* nicer, and of much
> more use if the name could be included in the default representation,
> both for classes and instances.
This will be fixed for classes when I fix the __name__ attribute. For
instances, I don't see how it can be fixed, since instances don't have
names when they are created. (If you write "x = C().init()", the
instance's name is *not* x -- all of Python's assignment semantics are
based on this fact...)
Cheers,
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>