Calling __init__ with multiple inheritance

jfj jfj at freemail.gr
Mon Mar 28 23:53:44 EST 2005


Peter Otten wrote:

> jfj wrote:
> 
>>Peter Otten wrote:
> 
>>>Here is an alternative approach that massages the initializer signatures
>>>a bit to work with super() in a multiple-inheritance environment:
>>
>>>        super(Father, self).__init__(p_father=p_father, **more)
>>
>>Is there any advantage using super in this case?
>>I think the case Father.__init__ (self, params) is simpler
>>and does the job perfectly well.
> 
> I agree.
>  

Ok. thanks for the confirmation.

> 
>>super seems to be needed in "Dynamic Inheritance" cases where
>>we don't know an object's bases and there are comlicated mro issues!
> 
> 
> Suppose you wanted factor out common code from the Father and Mother classes
> into a Parent class -- something neither complicated nor farfetched. With
> explicit calls to Parent.__init__() you would end up calling it twice from
> Child.__init__(). So when you anticipate that your class hierarchy may
> change, or that your classes may be subclassed by users of your library, I
> think super() is somewhat less errorprone.
> 

I accept the case that you avoid bugs if you extend the hierarchy
upwards.  Although that's rare.

As for the case where the users of the library want to subclass, I don't
see a problem.  They know they must subclass from class XXX and so they
call XXX.__init__ to construct it.

In the case of Parent diamond inheritance, super() can avoid calling
the __init__ of parent twice?  How?


jfj




More information about the Python-list mailing list