On 16 May 2013 03:06, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Wed, 15 May 2013 13:16:09 +0100, Oscar Benjamin wrote: > > >> I don't generally use super() > > Then you should, especially in Python 3. > > If you're not using super in single-inheritance classes, then you're > merely making your own code harder to read and write, and unnecessarily > difficult for others to use with multiple-inheritance. > > If you're not using super in multiple-inheritance[1] classes, then your > code is probably buggy. > > There really is no good reason to avoid super in Python 3.
I should have been clearer. I don't generally use super() because I don't generally use Python in a very object-oriented way. My comment was intended as a qualification of my advice rather than a suggestion that there is something wrong with super(). I can certainly see how that would be misinterpreted given the article I linked to: >> but I did see some advice about it in this article: >> https://fuhm.net/super-harmful/ > > It's not a good article. The article started off claiming that super was > harmful, hence the URL. He's had to back-pedal, and *hard*. The problem > isn't that super is harmful, it is that the problem being solved -- > generalized multiple inheritance -- is inherently a fiendishly difficult > problem to solve. Using super and cooperative multiple inheritance makes > it a merely difficult but tractable problem. > > The above article is useful to see the sorts of issues that can come up > in multiple inheritance, and perhaps as an argument for avoiding MI > (except in the tamed versions provided by mixins or straits). But as an > argument against super? No. I read that article when I was trying to do something with multiple inheritance. It was helpful to me at that time as it explained why whatever I was trying to do (I don't remember) was never really going to work. > > A much better article about super is: > > http://rhettinger.wordpress.com/2011/05/26/super-considered-super/ This is a good article and I read it after Ian posted it. > > >> From the conclusion: >> "Never use positional arguments in __init__ or __new__. Always use >> keyword args, and always call them as keywords, and always pass all >> keywords on to super." > > Even that advice is wrong. See Super Considered Super above. Raymond's two suggestions for signature are: ''' One approach is to stick with a fixed signature using positional arguments. This works well with methods like __setitem__ which have a fixed signature of two arguments, a key and a value. This technique is shown in the LoggingDict example where __setitem__ has the same signature in both LoggingDict and dict. A more flexible approach is to have every method in the ancestor tree cooperatively designed to accept keyword arguments and a keyword-arguments dictionary, to remove any arguments that it needs, and to forward the remaining arguments using **kwds, eventually leaving the dictionary empty for the final call in the chain. ''' The first cannot be used with object.__init__ and the second is not what the OP wants. I think from the article that the appropriate suggestion is to do precisely what the OP has done and make everything a subclass of a root class that has the appropriate signature. Perhaps instead of calling it my_object it could have a meaningful name related to what the subclasses are actually for and then it wouldn't seem so much like a dirty trick. > [1] To be precise: one can write mixin classes without super, and > strictly speaking mixins are a form of multiple inheritance, but it is a > simplified version of multiple inheritance that avoids most of the > complications. They're also mostly the only kind of multiple inheritance that I would think of using. Oscar -- http://mail.python.org/mailman/listinfo/python-list
