[Python-Dev] python and super
Hi all, I recently stumbled upon an issue with a class in the mro chain not calling super, therefore breaking the chain (ie, further base classes along the chain didn't get called). I understand it is currently a requirement that all classes that are part of the mro chain behave and always call super. My question is, shouldn't/wouldn't it be better, if python took ownership of that part, and ensured all classes get called, even if some class misbehaved? For example, if using a stack-like structure, pushing super calls and popping until the stack was empty, couldn't this restriction be removed? Thanks, Ricardo ___ 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
Re: [Python-Dev] python and super
Exactly what Michael said. Stopping the chain going upwards is one thing. Stopping it going sideways is another. On Thu, Apr 14, 2011 at 12:37 PM, Michael Foord wrote: > On 14/04/2011 16:34, 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). > > It shouldn't do. What I was suggesting is that a method not calling super > shouldn't stop a *sibling* method being called, but could still prevent the > *parent* method being called. > > Michael > > -- > http://www.voidspace.org.uk/ > > May you do good and not evil > May you find forgiveness for yourself and forgive others > May you share freely, never taking more than you give. > -- the sqlite blessing http://www.sqlite.org/different.html > > ___ 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
Re: [Python-Dev] python and super
> > 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. I'll give you the example I came upon: I have a TestCase class, which inherits from both Django's TestCase and from some custom TestCases that act as mixin classes. So I have something like class MyTestCase(TestCase, Mixin1, Mixin2): ... now django's TestCase class inherits from unittest2.TestCase, which we found was not calling super. Even if this is a bug and should be fixed in unittest2, this is an example where I, as a consumer of django, shouldn't have to be worried about how django's TestCase class is implemented. Since I explicitely base off 3 classes, I expected all 3 classes to be initialized, and I expect the setUp method to be called on all of them. If I'm assuming/expecting unreasonable things, please enlighten me. Otherwise, there you have a real-world use case for when you'd want the sibling classes to be called even if one class breaks the mro chain (in this case TestCase). Thanks, Ricardo ___ 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
