super() in class defs?

[Ian Kelly]

On Wed, May 25, 2011 at 3:40 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> If you actually read that article, carefully, without being fooled by the
> author's provocative ex-title and misleading rhetoric, you will discover
> that super is not harmful. What is harmful is making unjustified
> assumptions about what super does, and about the code you are calling,
> and hence misusing super.

Yes.  As others have noted, the problem is really multiple
inheritance, not super.  Super can be a useful tool, but unless you
have taken some time to learn its intricacies, I think that it is best
avoided so that it is not misused.

> You have to read all the way to the bottom of the article to see the
> author say in the TODO section:
>
> "Give some examples of why super really is necessary sometimes"
>
> Even before that, you will read why *not* using super often fails badly.
> If James Knight, the author, is correct that super is harmful, it seems
> that you're in trouble because *not using super* is also harmful.

Essentially, super can fail when you use it inconsistently.  Not using
super can fail when you have a diamond inheritance situation, or when
you mix it with super.

In this case, the OP is using super while inheriting from
http.server.CGIHTTPServer, which does not use super, and so is
inconsistent.

> If you search the mailing lists of python-dev at python.org, you will find a
> debate between James and Guido van Russum where James eventually
> acknowledges that he is wrong to call super harmful. There's a reason
> that he has changed the title of the page from "Python's Super Considered
> Harmful" to the damning-with-faint-praise "Python's Super is nifty, but
> you can't use it".

Thanks.  I found this quote from James that pretty much sums up my
position perfectly:

"""
This is where I'm coming from:
In my own code, it is very rare to have diamond inheritance structures.
And if there are, even more rare that both sides need to cooperatively
override a method. Given that, super has no necessary advantage. And it
has disadvantages.
- Backwards compatibility issues
- Going along with that, inadvertent mixing of paradigms (you have to
remember which classes you use super with and which you don't or your
code might have hard-to-find errors).
- Take your choice of: a) inability to add optional arguments to your
methods, or b) having to use *args, **kwargs on every method and call
super with those.
- Having to try/catch AttributeErrors from super if you use interfaces
instead of a base class to define the methods in use.
"""

> The new title is also *simply wrong*, because you can use it. James even
> tells you what you need to do to use it correctly.

Yes, you need to fundamentally alter the structure of your code to
throw away any semblance of run-time argument checking by having every
method that might conceivably be cooperatively inherited take *args,
**kwargs.  You also need to take care to always call super from such
methods, even when it appears to be unnecessary.  And don't forget to
catch the AttributeError if the method is something other than __new__
or __init__ and the current class turns out to be the last one in the
MRO that has it.

In short, if you're using super and don't feel burdened by it, then
you're probably using it incorrectly.

> The truth is that for multiple inheritance, you better be using super or
> your code is probably buggy (unless you manually duplicate what super
> does for you).

No.  For diamond inheritance, you better be using super or your code
is probably buggy.  For typical diamond-less multiple inheritance,
super is both unnecessary and tricky to use correctly.

> And for single inheritance, it makes no difference whether
> you use super or not.

Right.  It's unnecessary, so why saddle yourself with it?