super or not super?

[Antoon Pardon]

On 16/07/19 10:18, Chris Angelico wrote:
> On Tue, Jul 16, 2019 at 6:05 PM Antoon Pardon <antoon.pardon at vub.be> wrote:
>> On 16/07/19 09:18, Chris Angelico wrote:
>>> On Tue, Jul 16, 2019 at 3:32 PM Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>>> Just using super() is not enough. You need to take steps if you want to
>>>> ensure that you class plays nicely with MI. For example, consider the
>>>> following:
>>>>
>>>> class C1:
>>>>     def __init__(self, name):
>>>>         self._name = name
>>>>
>>>> class C2(C1):
>>>>     def __init__(self, name, value):
>>>>         super().__init__(name)
>>>>         self._value = value
>>>>
>>>> This usage of super is just fine for the single-inheritance shown here. But
>>>> there are two reasons why this cannot be neatly pulled into an MI
>>>> hierarchy. Can you spot both of them?
>>> Well, obviously it's violating LSP by changing the signature of
>>> __init__, which means that you have to be aware of its position in the
>>> hierarchy. If you want things to move around smoothly, you HAVE to
>>> maintain a constant signature (which might mean using *args and/or
>>> **kwargs cooperatively).
>> I guess the second problem is that C1 doesn't call super. Meaning that if
>> someone else uses this in a multiple heritance scheme, and the MRO reaches
>> C1, the call doesn't get propagated to the rest.
>>
> My understanding of this tiny hierarchy is that C1 is the root of the
> cooperative subtree. Example:

Why should that stop someone else from using C1 in it's own multiple
inheritance scheme? Since object is the root of the whole inheritance hierarchy
that should be workable.

I find it a bit odd to construct something so narrowly cooperative instead
of constructing it in a way that allows easier cooperation with future classes.

-- 
Antoon.