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 > > > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com