[Tutor] super() vs. explicitly calling base class?

[boB Stepp]

On Sat, Sep 21, 2019 at 10:31 AM Mats Wichmann <mats at wichmann.us> wrote:
>
> On 9/20/19 10:47 PM, boB Stepp wrote:
> > Python 3.7.4 on Linux Mint
> >
> > Assumption:  I have only TWO classes (Not concerned about 3+ class
> > inheritance scenario), Base and Child.  Is there any advantage to
> > using super() over explicitly calling Base from within Child?  My
> > following trivial example does not suggest any difference:
>
> The difference is that one way is hardwired and the other (as befits a
> dynamic language) is a computed indirect reference. That means in
> addition to protecting you from having to change references if you
> change the class hierarchy, you also have the opportunity to influence
> the way it resolves to the class it will delegate to.

My main point on asking about this is to be sure that I am not
overlooking any subtleties going on behind the scenes that could make
a meaningful difference.  Thankfully there do not seem to be any this
time!

So from your answer and the others', what I am taking away from this
is that super() is more flexible and easier to maintain IF I am happy
with super() triggering on the method or attribute in the immediate
next superclass with that name.  However, I imagine that if I *did*
have more than two classes involved in the inheritance chain *and* I
wanted not the next higher, say __init__(), but say the one a
superclass higher, then in that circumstance I would need to use that
class' actual name to access its __init__() method or whichever I am
interested in.

> If all that sounds too much it may actually be: if you *really* know for
> sure there will only ever be these two classes and you know exactly how
> they will be used, then fine, hardwire the relationship.  There are some
> people who don't think super is useful.  There's a famous paper that was
> written under the title "Python's Super Considered Harmful" - the author
> later retitled it "Python's Super is nifty, but you can't use it".
> Naturally, there's also work entitled "Super Considered Super"!

I'll have to search for links to these; sound interesting.  The "Super
Considered Super" sounds like a video I may have already viewed, but I
won't know until I check.

> Would just like to remind: that function there which prints "This is the
> Base class!" - isn't really "in" it.  The def statement causes a
> function object to be created, and a reference to that function object,
> with the name "__init__", goes into the dictionary that was created by
> the Base class definition. But it has no phyical attachment to Base...
> all it knows about is the instance object (plus remaining args - none in
> this case) it is passed - and the 2nd and 3rd times it runs it is
> actually running with a Child object. That makes zero difference if the
> work you're asking it to do is print a string, but it does have
> implications in designing more complex methods if super is going to be
> in play.  In particular, it means harmonizing the way arguments are
> handled by methods of the same name in a class hierarchy. Classes are
> ... "different" in Python :)

You got me on a technicality here!  I will try to be more precise next
time.  But this reminds me of a technique that I am repeatedly seeing
of "cleaning up" the remaining arguments using **kwargs.  I'm still
not sure I understand this in practice, so I will eventually pose a
more targeted question about this technique.

Thanks everyone!


-- 
boB