[Python-Dev] python and super

[Terrence Cole]

On Thu, 2011-04-14 at 17:10 +0100, Michael Foord wrote:
> On 14/04/2011 17:02, Raymond Hettinger wrote:
> > On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote:
> >
> >> At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
> >>> Ricardo isn't suggesting that Python should always call super for you, but when you *start* the chain by calling super then Python could ensure that all the methods are called for you. If an individual method doesn't call super then a theoretical implementation could skip the parents
> >>> methods (unless another child calls super).
> >> That would break classes that deliberately don't call super.  I can think of examples in my own code that would break, especially in __init__() cases.
> >>
> >> It's perfectly sensible and useful for there to be classes that intentionally fail to call super(), and yet have a subclass that wants to use super().  So, this change would expose an internal implementation detail of a class to its subclasses, and make "fragile base class" problems worse.  (i.e., where an internal change to a base class breaks a previously-working subclass).
> > I agree.  Better for someone to submit a recipe for a variant of super and see if there is any uptake.
> 
> In Python 3 super is treated specially by the compiler, so an 
> alternative implementation that behaves similarly to the built-in one 
> modulo this change is not possible.

I know that super does some astonishing *runtime* hackery with co_code
when you don't pass arguments, but I thought that was all that was
needed.  What does the compiler have to do specially for super that
would prevent somebody from implementing something like it?

> Two use cases for the suggested alternative behaviour have been 
> presented. What is the use case for a method not wanting to prevent its 
> *sibling* methods in a multiple inheritance situation being called?
> 
> I believe the use case Phillip (and others) have presented is for 
> methods preventing their *parent* methods being called.
>
> All the best,
> 
> Michael Foord
> 
> >
> > Raymond
> >
> 
>