class super method

[Ed Leafe]

On Apr 1, 2008, at 8:43 AM, George Sakkis wrote:

> Did you follow the links I gave by any chance? With all the gotchas
> and rules of how to use it properly, it's far from what I would call
> elegant.

	Please. Anything powerful can be dangerous if used indiscriminately.  
But in a language that supports multiple inheritance, it is amazingly  
elegant to use a simple function to create a superclass object for a  
class with multiple mixins at various levels of the inheritance  
hierarchy that "just works". Yes, having to specify the current class  
is a bit of a wart that is being addressed in 3.0, but the approach is  
still the same.

> Pehaps, at least as long as you make sure that all superclasses have a
> compatible signature - which in practice typically means accept
> arbitrary *args and **kwargs in every class in the hierarchy like your
> example. Good luck figuring out what's wrong if it's not used
> consistently.

	See my comment above. If you do not know what you're doing, you  
shouldn't be doing it. This is not the fault of super(); it's the  
fault of a poor programmer. And I used generic *args and **kwargs in  
the method sig since I was using made-up class names and methods.  
Would you have reacted more favorably if I had used (self, foo, bar)  
instead?

> Also doOurCustomStuffBeforeTheSuperCall() works as long as all
> ancestor methods to be called need the same CustomStuff massaging.

	Oh, c'mon. Of course that's the case; if you are overriding method  
behavior, it is your job as the programmer to ensure that. Again, this  
is nothing to do with the super() function, and everything to do with  
the abilities of the developer.

> In a sentence, it's better than nothing but worse than anything.


	I guess I must be the world's most amazing Python developer, as I've  
used super() extensively for years without ever suffering any of the  
pitfalls you and others describe.

-- Ed Leafe