[issue38262] Mixins - super calls in bases of multiple-inheritance with different parameters

[Steven D'Aprano]

Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Tue, Sep 24, 2019 at 08:54:49PM +0000, Arno-Can Uestuensoez wrote:

> Or reduced to the focus of the actual issue and depicted the actual 
> passed parameters. See the following "Case 4 - same as 
> mixin_C_is_B0A1" for the essential question.

> Case 4 - same as mixin_C_is_B0A1
> 
>   B_Without_Arg:C True
>   A_With_Arg:C False
> 
>   success
> 
> Comment:
>   The success is NOT expected and as far as I can see should be treated as an Error so NOK.

Why would it be an error when you override object.__init__ completely? 
object.__init__ doesn't get called at all, because A overrides it:

    class A(object):
        def __init__(self, propagate=False):
            if propagate:
                super(A, self).__init__(propagate)
            # this section is implied
            else:
                pass  # override the superclass

B_Without_Arg calls ``super().__init__`` with no arguments, so 
``A.__init__`` fills in the default argument, propagate=False.

[...]
>      This means the call of "super(B, self).__init__()" within 
>      "B.__init__()" defines the call parameters of "A.__init__()". 

Yes, that's how it works in cooperative multiple inheritance.

It may help to read this:

https://www.artima.com/weblogs/viewpost.jsp?thread=281127

The very badly named essay "Super considered harmful" is also worth 
reading. It is badly named because it is not *super* which is painful, 
and the author eventually was forced to admit that super is the best 
available solution to the complications of multiple inheritance.

http://fuhm.net/super-harmful/

Somewhere on Youtube you should be able to find a video of a talk given 
by Raymond where he discusses ways to solve multiple inheritance 
problems. Sorry I don't remember what it is called.

>      Even though I expect the call order as routed by the MRO, 
>      I did not expected the parameters of A to be passed from the
>      sibling class B, but as defined by the base class C. 

I think I've made that same mistake too. Perhaps the documentation 
should make this aspect of multiple inheritance more clear.

I think that we have established that, whether you expected it or not, 
the behaviour you show is the way Python multiple inheritance has worked 
since version 2.3 and is working as designed.

If you want to debate that design, the bug tracker is not the right 
place for it, and you should take it to the Python-Dev mailing list. It 
might be more productive to ask the mailing list why that design choice 
was made, before asserting that it is wrong.

If you aren't fond of mailing lists, you could try the Python Discuss:

https://discuss.python.org/

but either way, I think that this issue should be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38262>
_______________________________________