super() doesn't get superclass

[Carl Banks]

On Tue, 18 Sep 2007 15:38:46 +1000, Ben Finney wrote:
> Evan Klitzke <evan at yelp.com> writes:
> 
>> If you're using multiple inheritance, and you're _not_ using super
>> everywhere, then your code is broken anyway.
> 
> This seems to support the notion that 'super' is unusable. If I inherit
> from code that isn't under my control, and then use super(), my code is
> broken.
> 
> Therefore, to avoid writing broken code, I must either never inherit
> from code not under my control, or I must never use super(). Since the
> former is practically unavoidable, I must choose the latter.
> 
> Which, naturally, compounds the problem, since when someone else uses
> *my* code, they in turn must conclude that they can't use super().

I'm sorry, but you can't inherit from someone else's classes and not 
worry about what they're doing.  Whether they use super or not is only 
one possible concern.  It's not like the super destroyed the magical 
utopia where you could derive from other people's classes without worry.

In any case, it's just as problematic if you don't use super and your 
base classes do.  By your logic, your code is "broken" no matter what you 
do, and so the only "conclusion" you can come to is never to derive from 
classes that aren't under your control.

(Which, frankly, isn't all that bad a conclusion.  In 8 years of Python 
programming, I've inherited from exactly one class that wasn't under my 
control: Thread.  It's not "practically impossible" to avoid, at least 
not for me.)


>> Use super correctly in your own code, and you don't need to worry about
>> other people using it incorrectly.
> 
> As the article points out, when using super(),
> 
>     you must remember that super does not call your superclass. You must
>     be prepared to call any other class's method in the hierarchy and be
>     prepared to be called from any other class's method.
> 
> So, the programmer using super() very much *does* need to worry about
> other people using it correctly.

Yes.  Welcome to programming.


Carl Banks