super or not super?

[Chris Angelico]

On Tue, Jul 16, 2019 at 3:32 PM Ian Kelly <ian.g.kelly at gmail.com> wrote:
>
> On Sun, Jul 14, 2019 at 7:14 PM Chris Angelico <rosuav at gmail.com> wrote:
> >
> > On Mon, Jul 15, 2019 at 10:51 AM Paulo da Silva
> > <p_s_d_a_s_i_l_v_a_ns at netcabo.pt> wrote:
> > >
> > > Às 15:30 de 12/07/19, Thomas Jollans escreveu:
> > > > On 12/07/2019 16.12, Paulo da Silva wrote:
> > > >> Hi all!
> > > >>
> > > >> Is there any difference between using the base class name or super to
> > > >> call __init__ from base class?
> > > >
> > > > There is, when multiple inheritance is involved. super() can call
> > > > different 'branches' of the inheritance tree if necessary.
> > > > ...
> > >
> > > Thank you Jollans. I forgot multiple inheritance. I never needed it in
> > > python, so far.
> > >
> >
> > Something to consider is that super() becomes useful even if someone
> > else uses MI involving your class. Using super() ensures that your
> > class will play nicely in someone else's hierarchy, not just your own.
>
> 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'm not sure what the second issue is, though. It's kinda hard to
imagine a real-world situation where this would come up (some things
have names but not values, others have values... what third class
could you bring in that would make sense here?), so I'm unsure whether
you're pointing to "self._value" as a problem. Personally, I'd use
"self.value = value" and not try to pretend that it's private. (Not a
fan of "self.__value" because subclasses can't use it usefully AT ALL,
so unless you're absolutely perfectly maintaining a consistent public
signature - which you're not, see the first point - there's no way you
can do anything good with it.)

ChrisA