Flagging classes as not intended for direct initialization

[Mario Figueiredo]

On Tue, 17 Feb 2015 01:11:01 +1100, Chris Angelico <rosuav at gmail.com>
wrote:

>So what you have here is not "super() is weird", but "multiple
>inheritance is messy, and this is how Python handles it".
>

I'd say the diamond pattern is messy. MI is otherwise a pretty
peaceful kid without it.

I don't find the C3 linearization method particularly hard to
understand either. Contrary to Mark, I don't look at MRO as some
esoteric property of Python. Heck, took me more time to understand and
take advantage of tuple packing and unpacking, than it took me to
understand MRO.

What may make MRO complex is large hierarchic trees, defined across
multiple modules. But that really is complex under any method
resolution model we can think of. Under those circumstances, proper
documentation is the solution whether one is using C3 linearization
(which really isn't exclusive to Python) or something else, like
explicit naming or depth search rules.

What really put me off was instead the mention to lack of support for
variadic methods and some apparent problems with operator overloading.
I reasoned that for the sake of consistency, I'm probably better using
super only when I need its specific set of features.

>Explicit naming of superclasses is fragile for several reasons.
>Firstly, it breaks the parallel between "method which calls its
>superclass method" and "absence of method, and implicit referral to
>superclass" (as the latter guarantees to use the MRO);

I agree. Super is more explicit than an explicit method call. Which is
ironic. Both in fact can coexist, with explicit method calls being
used to denote an MRO deviation, for instance.

But frankly, I don't see the breaking of that  parallel as a problem.
For the most part, you can code in complete ignorance of MRO, even in
the presence of MRI. MI name clashing is something that we ought to
avoid anyways and it is so rare we ever have to confront it, that
making a case for super on that basis is a bit weak.

> and secondly,
>you end up writing your superclass name a lot of times. Though, to be
>honest, the Py2 super() syntax has the same issue, just with your own
>class name. With the Py3 shorthand syntax, you're not rewriting
>everything all over the place.

I do like the super syntax better. I rewrote my code to include it, as
advised earlier. After looking at the link Steven provided and reading
a bit more about here, I decided to go with it instead in in single
hierarchy classes.

But I have to agree with Mark that the case for super is a bit weak.
The arguments for it are based on MI edge cases which really doesn't
translate well to "super is better than explicit method calling".