[Tutor] subclasses and conflicting variables

[Magnus Lycka]

At 18:35 2003-01-11 -0700, Poor Yorick wrote:
>I understand when inheriting multiple classes, if there is an instance 
>identifier name conflict, the leftmost inherited class takes priority.

Actually, this has changed for the so called "diamond rule"
in version 2.2 of python. What you say is true if the base
classes don't have common heritage. See
http://www.python.org/2.2/descrintro.html#mro

>In the following code, instance.var1 = 'hello'.  It seems to me that this 
>behavior could wreak havoc in multiple layers of inheritance.  In the code 
>below, is there any way for instance to access classB.var1?

If you need that, you might have misused multiple inheritance (MI).

That variables hide each other is nothing specific for inheritance
though. You can hide globals with locals, builtins with globals
or locals and so on. In most language, but not in Python, you can
hide attributes in classes with locals.

But going back to MI, it's probalby a good idea to restrict its use
to some special cases. We used to have a commercial for some kind of
baby stuff on TV with a woman saying "I'm not just a nurse, I'm a
mother as well..." Translated to Python you might write:

class Person:
     ...

class Mother(Person):
     ...

class Nurse(Person):
     ....

class NurseAndMother(Nurse, Mother):
     ...

This is probably a bad idea though. I typically advice against
using multiple inheritance in the object model that represent
the business analysis, and to reserve MI to more technical aspects.
This might be features like logging or persistence that you "plug
in" to other classes.

In my current project, I only use MI in 2 of 135 classes, and I
think that is a reasonable proportion. In this case, it's one class
that inherits UserString.UserString and ZODB's Persistence.Persistent,
and another in the wxPython GUI that inherits wxListCtrl and
wxListCtrlAutoWidthMixin. The wxListCtrlAutoWidthMixin is designed
specifically to provide some extra features to wxListCtrl.

In Java, it is at least claimed that, the reason to leave out
MI was that it's often used in a way that causes problems. Instead,
Java has interfaces which means that you have to duplicate
implementations. :(

In Python, as in C++, you have the choice to use MI where it
fits, and the responsibility to not use it in situations where
it will cause problems.

While Python is considered a "beginner friendly" language, and
a language where there is often "one way to do it", as opposed
to the kind of confusion that e.g. Perl offers, this doesn't mean
that useful features are left out because they are abused now
and then. Guido is not taking responsibility for your programs.
He provides you with an efficient tool that will usually be
helpful and which doesn't contain a multitude of complications
to prevent you from shooting yourself in the foot. It does contain
features that both makes programming faster and reduces the risk
of injuries, such as automatic memory management and easy to use
high level constructs as lists and dictionaries, but it's certainly
not a padded cell... If you bang your head in the wall, it will be
painful.

It's interesting that Guido discussed "language levels" in the
Computer Programming For Everybody (CP4E) program, which was
cancelled due to lack of funding. I can guess that MI might
have been among the things that would have been disabled at the
beginner level of Python.




-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se