[Python-Dev] Things to Know About Super

[Raymond Hettinger]

[Michele Simionato]
> Recently I have opened a blog on Artima and I am publishing a
> few Python-related essays I had in store. In particular a trilogy
> of papers about "super". From the foreword:
> 
> """
> In 2004 I decided to write a comprehensive paper documenting
> ``super`` pitfalls and traps,  ...

Thanks for posting these blogs.  I think they serve as a nice 
compilation of docs, original analysis, and various discussions on super().

What I would really like to see is a fourth blog entry that shows
how to use super() reliably and correctly.  In general, I opposed
to creating documentation in the form of "danger, danger this
could explode ...."   IMO, there is not much point in dwelling on
bugs that have already been fixed, nor is there an advantage to
showing all the ways the tool can be misused.

In applications without multiple inheritance, it is a straight-forward
to use super() as a way to avoid directly naming an immediate 
parent class. This is useful in and of itself.

For cooperative multiple inheritance, I take issue with the abstracted
examples provided (i.e. inconsistent signatures).  In a real app that
actually needs cooperative multiple inheritance, it becomes self-evident
what "cooperative" actually means -- the methods *have* to be
designed to interoperate -- it is intrinsic to the problem at hand.

Your reasoning is akin to saying that cooperative multitasking is intrinsically
flawed because one of the tasks could be designed to not cooperate
(never yield).

Cooperative multiple inheritance is *not* about mixing two unrelated
parents that just happen to use the same method name but have
different semantics and were not designed to cooperate with each other.

The A-B-C-D diagrams and foo/bar methods in the examples are
deceptive because they silently drop the precondition of cooperation
while attempting to demonstrate a supposed flaw in the tool.

If I understand the problem correctly, in the rare cases where you do
need cooperative multiple inheritance, then super() is the only workable
solution short of designing some equivalent using composition instead
of inheritance.

I do agree with you that the docs can be improved.  I'll work on patch
that makes clear that super() returns a proxy-object (not an actual 
parent class) that dispatches explict method calls (not syntax driven)
to one of multiple parents designed to interact cooperatively.

Also, it may be controversial, but there may be some merit in 
de-documenting the "unbound" case.  It seems to add more 
confusion than it's worth.

Lastly, I take issue with one other part of the blogs.  While they show
a clear dislike for cooperative multiple inheritance, they take a potshot
at multiple inheritance in general.  I don't follow the logic here.  IMO,
mixin classes like DictMixin have proven themselves as being very
useful.  Plenty of frameworks share this approach.  Likewise, the
new ABCs offer mixin capabilities that are really nice.

I think it is a non-sequiter to reason from "diamond diagrams are
complicated" to "mixins should be disallowed".  Instead, I think it 
better to simply recommend that a key to happiness is to keep 
various mixin classes completely orthogonal to one another 
(no overlapping method names).

Lest I sound negative, let me thank you again for the blog entries
and for compiling the most complete discussion of it in one place.


Raymond