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
--
http://mail.python.org/mailman/listinfo/python-list
