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