I noticed that the many (if not all) classes in threading.py[1] all
inherit from object, yet non of the init methods call super(). I am
curious as to why this is the chosen implementation? If the benefit of
new-style classes is to support multiple inheritance, then isn't this
"broken" if the class __init__ method does not make a call to super?
The Python language supports multiple inheritance but it doesn't mean
all classes are required to support it.
Anyway, I wouldn't recommend using MI on classes you (or your company)
don't control yourself, unless the class is explicitly documented as
supporting MI. (For that matter, I wouldn't recommend single
inheritance in that situation.)
This is not just because of issues with super. Inheritance is
trickier than most people expect; you can't reliably inherit without
knowing and depending on some implementation details of the base class
(**). This is true even without super's defects.
If the base class is under your control, no problem, multiply inherit
at will. If the base class is documented as supporting multiple
inheritance, then you are fairly safe because the class is unlikely to
change in such a way as to break any derived classes. So go ahead.
If neither applies, well you're on your own.
Carl Banks
(**) For instance, some container class might define a __setitem__
method, and also some higher level methods like add. If you want to
subclass it, can you just override __setitem__, or do you have to
override higher-level methods like add also? You don't know unless
you know how add is implemented.
A lot of people seem to think that all you need to know about the base
class to inherit from it is the interface, or rather, it would be all
you'd need to know if not for the super issue. Then they turn around
and complain that super is broken because it is the only thing
preventing us from reaching this panacean realm where one can inherit
from any base class at all without care. Alas it was never so. Care
has always been required when inheriting.
