G
gigs
is there any tutorial for super method (when/how to use it)?
or maybe someone could explain me how it works?
thx
or maybe someone could explain me how it works?
thx
is there any tutorial for super method (when/how to use it)?
or maybe someone could explain me how it works?
thx
is there any tutorial for super method (when/how to use it)?or maybe someone could explain me how it works?
Super is one of the dark corners of the language [1,2]... a good rule
of thumb is to stay away from it, or at least stick to its basic
usage.
George
[1]http://www.phyast.pitt.edu/~micheles/python/super.html
[2]http://fuhm.net/super-harmful/
is there any tutorial for super method (when/how to use it)?
or maybe someone could explain me how it works?
thx
Super is one of the dark corners of the language [1,2]... a good rule
of thumb is to stay away from it, or at least stick to its basic
usage.
I've also found myself wondering:
1. What are the two arguments to super used for?
2. What happens when the method supplied *after* the super is
different from the containing method?
In the above example what happens if:
class DaboUIClass(dabo.ui.dControlMixin, someWxPythonClass):
def __init__(self, *args, **kwargs):
doOurCustomStuffBeforeTheSuperCall()
super(DaboUIClass, self).callRandomMethod(foobar)
doOurCustomStuffAfterTheSuperCall()
Super is one of the dark corners of the language [1,2]... a good rule
of thumb is to stay away from it, or at least stick to its basic
usage.
I disagree - super is quite elegant and dependable.
In my own project (Dabo), we use mixin classes liberally to provide
consistent behavior across our UI classes. The use of super makes
customizing __init__() behavior, for example, quite straightforward.
The general form looks like:
class DaboUIClass(dabo.ui.dControlMixin, someWxPythonClass):
def __init__(self, *args, **kwargs):
doOurCustomStuffBeforeTheSuperCall()
super(DaboUIClass, self).__init__(*args, **kwargs)
doOurCustomStuffAfterTheSuperCall()
This has worked reliably for us in every place where we have used it.
There's nothing dark and mysterious about it at all.
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.
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.
Also doOurCustomStuffBeforeTheSuperCall() works as long as all
ancestor methods to be called need the same CustomStuff massaging.
In a sentence, it's better than nothing but worse than anything.
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?
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.
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?
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.
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.
I disagree - super is quite elegant and dependable.
Because Python support multiple inheritance, it is difficult to
manually ensure that when augmenting a method that the correct
superclass calls are made. super() handles that without having to
guess as to what the correct inheritance hierarchy is.
In my own project (Dabo), we use mixin classes liberally to provide
consistent behavior across our UI classes. The use of super makes
customizing __init__() behavior, for example, quite straightforward.
The general form looks like:
class DaboUIClass(dabo.ui.dControlMixin, someWxPythonClass):
def __init__(self, *args, **kwargs):
doOurCustomStuffBeforeTheSuperCall()
super(DaboUIClass, self).__init__(*args, **kwargs)
doOurCustomStuffAfterTheSuperCall()
This has worked reliably for us in every place where we have used it.
There's nothing dark and mysterious about it at all.
It is just that you did not run (yet) in a corner case of super. The
interesting question would be: did any of your users run into issues
using you library which is heavily relying on super? Especially when
composing it with their own classes?
I personally have changed my opinion about multiple inheritance over
the years.
At the beginning I thought it was a very cool idea, but now I think it
is a pretty bad idea. If I were to design a language, I would not
implement multiple inheritance. In Python I never use multiple
inheritance and actually I try very hard to avoid even single
inheritance, preferring composition whenever it is viable.
So you are prepared to write off the voice of experience because someGeorge said:I disagree - super is quite elegant and dependable.is there any tutorial for super method (when/how to use it)?
or maybe someone could explain me how it works?
thx
Super is one of the dark corners of the language [1,2]... a good rule
of thumb is to stay away from it, or at least stick to its basic
usage.
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.
In my own project (Dabo), we use mixin classes liberally to provide
consistent behavior across our UI classes. The use of super makes
customizing __init__() behavior, for example, quite straightforward.
The general form looks like:
class DaboUIClass(dabo.ui.dControlMixin, someWxPythonClass):
def __init__(self, *args, **kwargs):
doOurCustomStuffBeforeTheSuperCall()
super(DaboUIClass, self).__init__(*args, **kwargs)
doOurCustomStuffAfterTheSuperCall()
This has worked reliably for us in every place where we have used it.
There's nothing dark and mysterious about it at all.
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.
Also doOurCustomStuffBeforeTheSuperCall() works as long as all
ancestor methods to be called need the same CustomStuff massaging.
In a sentence, it's better than nothing but worse than anything.
Lest my remarks should be thought disrespectful to Michele Simionato, ISteve said:So you are prepared to write off the voice of experience because some
random web pages contradict what Ed is saying?
As Ed rightly points out, any sufficiently complex gun can end up
shooting you in the foot.
Ed is a good enough designer to avoid the corner cases. Strangely
enough
the one place where I have ended up making significant use of super()
was in providing mixins for wxPython interface classes!
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.