When deriving from a builtin type as well as from some other class, it seems that the builtin type's constructor doesn't call the super class constructor. This results in __init__ methods not being called for types that come after the builtin in the MRO.
Example:
class A:
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
print("A().__init__()")
class B(list, A):
def __init__(self, *args, **kwargs):
print("B().__init__() start")
super().__init__(*args, **kwargs)
print("B().__init__() end")
if __name__ == '__main__':
b = B()
In this sample, A.__init__ is never called. When B is defined as class B(A, list)
instead -- switching the inheritance order -- it works as intended (i.e. A.__init__ is called).
This very subtle dependence on inheritance order seems rather un-pythonic, is it intended this way? It also means that you must never derive from builtin types in complex class hierarchies, because you can't know where the builtin ends up in the MRO when someone else derives from your classes (maintenance horror). Am I missing something?
Extra info: Python version 3.1
When you initialize a child class in Python, you can call the super(). __init__() method. This initializes the parent class object into the child class. In addition to this, you can add child-specific information to the child object as well.
__init__() doesn't really do anything differently for Cube than it already does for Square , you can skip defining it, and the . __init__() of the superclass ( Square ) will be called automatically. super() returns a delegate object to a parent class, so you call the method you want directly on it: super().
The super() function is used to give access to methods and properties of a parent or sibling class. The super() function returns an object that represents the parent class.
In general it is necessary. And it's often necessary for it to be the first call in your init. It first calls the init function of the parent class ( dict ).
The correct usage of super()
is rather subtle and requires some care if the collaborating methods don't all have the same signature. The usual pattern for __init__()
methods is the following:
class A(object):
def __init__(self, param_a, **kwargs):
self.param_a = param_a
super(A, self).__init__(**kwargs)
class B(A):
def __init__(self, param_b, **kwargs):
self.param_b = param_b
super(B, self).__init__(**kwargs)
class C(A):
def __init__(self, param_c, **kwargs):
self.param_c = param_c
super(C, self).__init__(**kwargs)
class D(B, C):
def __init__(self, param_d, **kwargs):
self.param_d = param_d
super(D, self).__init__(**kwargs)
d = D(param_a=1, param_b=2, param_c=3, param_d=4)
Note that this requires that all methods collaborate, and that all methods need a somewhat compatible signature to ensure it does not matter at which point the method is called.
The constructors of built-in types don't have constructor signatures that allow participating in such a collaboration. Even if they did call super().__init__()
this would be rather useless unless all the constructor signatures were unified. So in the end you are right -- they are not suitable for particpation in collaborative constructor calls.
super()
can only be used if either all collaborating methods have the same signature (like e.g. __setattr__()
) or if you use the above (or a similar) pattern. Using super()
isn't the only pattern to call base class methods, though. If there are no "diamonds" in your multiple inheritance pattern, you can use explicit base class calls, for example B.__init__(self, param_a)
. Classes with multiple base classes simply call multiple constructors. An even if there are diamonds, you can sometimes use explicit calls, as long as you take care that an __init__()
may be called several times without harm.
If you want to use super()
for contructors anyway, you indeed shouldn't use subclasses of built-in types (except for object
) in multiple inheirtance hierachies. Some further reading:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With