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
-- http://mail.python.org/mailman/listinfo/python-list
