Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > class super method

Reply
Thread Tools

class super method

 
 
gigs
Guest
Posts: n/a
 
      03-31-2008
is there any tutorial for super method (when/how to use it)?

or maybe someone could explain me how it works?

thx
 
Reply With Quote
 
 
 
 
George Sakkis
Guest
Posts: n/a
 
      03-31-2008
On Mar 31, 6:25 pm, gigs <(E-Mail Removed)-com.hr> wrote:
> 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.

George


[1] http://www.phyast.pitt.edu/~micheles/python/super.html
[2] http://fuhm.net/super-harmful/
 
Reply With Quote
 
 
 
 
castironpi@gmail.com
Guest
Posts: n/a
 
      03-31-2008
On Mar 31, 5:58*pm, George Sakkis <(E-Mail Removed)> wrote:
> On Mar 31, 6:25 pm, gigs <(E-Mail Removed)-com.hr> wrote:
>
> > 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.
>
> George
>
> [1]http://www.phyast.pitt.edu/~micheles/python/super.html
> [2]http://fuhm.net/super-harmful/


Is ancestry mutable?
 
Reply With Quote
 
Ed Leafe
Guest
Posts: n/a
 
      04-01-2008
On Mar 31, 2008, at 5:58 PM, George Sakkis wrote:

>> 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 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.

-- Ed Leafe



 
Reply With Quote
 
Ed Leafe
Guest
Posts: n/a
 
      04-01-2008
On Apr 1, 2008, at 7:23 AM,
brooklineTom@gmail_spam_blocking_suffix.com wrote:

> I've also found myself wondering:
>
> 1. What are the two arguments to super used for?


To determine the type (1st arg) for which the superclass hierarchy is
to be determined, and the instance (2nd arg) if the super object is to
be bound. In typical usage, they are the class of the current
instance, and the 'self' reference to the instance.

> 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() returns an object that doesn't "know" in what method it was
derived, so as long as the superclass has the 'callRandomMethod'
method, and 'foobar' is defined, there is no problem at all. IOW, the
only context is the class of the instance, not any particular method
of the instance.

You could also do something like this:

class DaboUIClass(dabo.ui.dControlMixin, someWxPythonClass):
def __init__(self, *args, **kwargs):
doOurCustomStuffBeforeTheSuperCall()
self.super = super(DaboUIClass, self)
self.super.__init__(*args, **kwargs)
doOurCustomStuffAfterTheSuperCall()

def someMethod(self, foo, bar):
self.super.someMethod(foo, bar)

def someOtherMethod(self):
self.super.someOtherMethod()

-- Ed Leafe



 
Reply With Quote
 
George Sakkis
Guest
Posts: n/a
 
      04-01-2008
On Mar 31, 10:41 pm, Ed Leafe <(E-Mail Removed)> wrote:

> On Mar 31, 2008, at 5:58 PM, George Sakkis wrote:
>
> >> 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 disagree - super is quite elegant and dependable.


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.

George
 
Reply With Quote
 
Ed Leafe
Guest
Posts: n/a
 
      04-01-2008
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



 
Reply With Quote
 
George Sakkis
Guest
Posts: n/a
 
      04-01-2008
On Apr 1, 10:21 am, Ed Leafe <(E-Mail Removed)> wrote:

> On Apr 1, 2008, at 8:43 AM, George Sakkis wrote:
> > 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?


No, that was exactly my point; with a non-generic signature like
(self, foo, bar), it's a matter of time until some subclass breaks it.
Non-trivial hierarchies with all __init__ having compatible signatures
is not typical in my experience, but they have to be compatible to be
used correctly with super. Here is the conclusion from the second
article I linked:

'''
If you do use super, here are some best practices:

* Use it consistently, and document that you use it, as it is part
of the external interface for your class, like it or not.
* Never call super with anything but the exact arguments you
received, unless you really know what you're doing.
* When you use it on methods whose acceptable arguments can be
altered on a subclass via addition of more optional arguments, always
accept *args, **kw, and call super like "super(MyClass,
self).currentmethod(alltheargsideclared, *args, **kwargs)". If you
don't do this, forbid addition of optional arguments in subclasses.
* 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.
'''

> > 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.


Some people use the same argument for explicit memory management in C/C
++. Sure, it can be done, but that doesn't make it elegant or trivial.
When experts like Michele Simionato find super() tricky enough to
write an article about it, that says something.

George
 
Reply With Quote
 
Gabriel Genellina
Guest
Posts: n/a
 
      04-01-2008
En Tue, 01 Apr 2008 11:21:48 -0300, Ed Leafe <(E-Mail Removed)> escribió:
> On Apr 1, 2008, at 8:43 AM, George Sakkis wrote:
>
>> 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?


Then *all* classes must use exactly the same signature for that method.
You don't know which one will be the next class in the MRO order used by
super() so you can't adjust the arguments in any way.
In the case of __init__, the only practical way is to make all of them
take keyword arguments exclusively and use *args and **kwarsg.
See the earlier links for a simple failing example.

>> 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.


How do you know that? super may call a method on a different class that is
*not* an ancestor of the current class. Again, for examples, see the
earlier links.

>> 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.


Maybe you're a very lucky man!

--
Gabriel Genellina

 
Reply With Quote
 
Michele Simionato
Guest
Posts: n/a
 
      04-01-2008
On Apr 1, 4:41 am, Ed Leafe <(E-Mail Removed)> wrote:
> 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.

Michele Simionato
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Accessing super-class methods from super-class fi3nd Java 0 04-08-2010 03:10 PM
A need for super.super.method() zweibieren Java 0 05-06-2009 11:36 PM
super.super.super how? Java 24 02-24-2005 10:51 PM
$class::SUPER as well as $instance::SUPER? Matthew Braid Perl Misc 2 08-09-2004 12:05 AM
Getting the super class via the super() function Fernando Rodriguez Python 2 11-22-2003 12:08 AM



Advertisments