Pupeno <[EMAIL PROTECTED]> wrote:
> class MyConfig(ConfigParser, object):
>     def add_section(self, section)
>          super(MyConfig, self).add_section(section)
> 
> seems to work and as expected. Is there anything wrong with it ?

yes. 

(1) There's a colon missing in the def-line. ;-)

(2) The folling doesn't work as you might expect:

----------------------------------------------8<---------------
from ConfigParser import ConfigParser
class MyConfig(ConfigParser, object):
    def add_section(self, section):
        print "in MyConfig"
        super(MyConfig, self).add_section(section)

class AnotherConfig(object):
    def add_section(self, section):
        print "in AnotherConfig"
        super(AnotherConfig, self).add_section(section)

class TheConfigIReallyUse(MyConfig, AnotherConfig):
     def add_section(self, section):
         print "in TheConfigConfigIReallyUse"
         super(TheConfigIReallyUse, self).add_section(section)

a = TheConfigIReallyUse()

a.add_section(None)
---------------------------------------------->8---------------

If you call this little script, you get ...

----------------------------------------------8<---------------
in TheConfigConfigIReallyUse
in MyConfig
---------------------------------------------->8---------------

..., i. e. add_section in AnotherConfig won't be called.

The reason for this is, that the usage of "super" (or it's non-usage 
in this case) is part of the interface of a class. ConfigParser doesn't 
support super (as most if not all classes in the standard lib),
therefore it doesn't ensure AnotherConfig's add_section will be called
at an appropriate time. This call just gets lost.

In my world you should never user super with the only exception being
that you really know what you are doing. ;-) In fact, super is a cool
thing for non-trivial diamond shape inheritance (i.e. not counting
object to introduce the diamond shape, otherwise this would make every 
multiple inheritance of new style classes a diamond shape). Even then
you have to be careful, that all methods must have the same signature
(*args and **kwargs may help you with this), because in the end you
never know which class calls which other class next. (Well, yes, you
may find out, but the next inheritance may break this again.)

In the end it comes down to: 
(1) If you use diamond shape inheritance (or might in the
    future), then use super.  
(2) If your base classes support super, use super. 
(3) If (1) goes without (2) be extra careful.
(4) Whatever you do, read the documentation of super and try to
    understand what you are doing.
(5) If you want to know about the flamewar sourrounding this issue,
    google for "python", "super" and "harmful"...

Cheers,
  --Jan Niklas
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to