On 14 Apr, 2011, at 18:10, 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. > > 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.
What would the semantics be of a super that intentially calls all siblings? In particular what is the return value of such a call? The implementation can't know how to combine the implementations in the inheritance chain and should refuse the tempation to guess. Ronald _______________________________________________ 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
