[Python-Dev] python and super (original) (raw)

Terrence Cole list-sink at trainedmonkeystudios.org
Thu Apr 14 23:56:50 CEST 2011

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 >

More information about the Python-Dev mailing list