By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,050 Members | 1,020 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,050 IT Pros & Developers. It's quick & easy.

multiple inheritance

P: n/a
Hi.

I think I'm missing something about multiple inheritance in python.

I've got this code.

class Foo:
def __init__(self):
self.x = "defined by foo"
self.foo = None

class Bar:
def __init__(self):
self.x = "defined by bar"
self.bar = None

class Foobar(Foo,Bar):
pass

fb = Foobar()
print fb.x
print fb.__dict__

which returns :
defined by foo
{'x': 'defined by foo', 'foo': None}

So I guess not defining __init__ in my class Foobar will call __init__
from my superclass Foo. Also __dict__ doesn't show an attribute
'bar':None so I guess Bar.__init__ is not called at all.

I would like to have a subclass with all attributes from superclasses
defined, and only the attribute from the first when there is conflict
(i.e. in this case, Foobar would be like this but with bar:None)

I tried this :

class Foobar(Foo,Bar):
def __init__(self):
Foo.__init__(self)
Bar.__init__(self)

defined by bar
{'x': 'defined by bar', 'foo': None, 'bar': None}

Here I have all I want, except the value of 'x' comes from the 'Bar'
superclass rather than Foo. So, to have what I want, I would have to
invert the two calls to __init__ in order to have the right x value.

What I find awkward here is that the order of __init__ calls matters,
rather than the order of the classes in the class declaration.

Do you have any ideas of a way to get this multiple inheritance thing
solved without having to do those __init__ calls ?

Thomas

Feb 15 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a

Thomas Girod a écrit :
Hi.

I think I'm missing something about multiple inheritance in python.

I've got this code.

class Foo:
def __init__(self):
self.x = "defined by foo"
self.foo = None

class Bar:
def __init__(self):
self.x = "defined by bar"
self.bar = None

class Foobar(Foo,Bar):
pass

fb = Foobar()
print fb.x
print fb.__dict__

which returns :
defined by foo
{'x': 'defined by foo', 'foo': None}

So I guess not defining __init__ in my class Foobar will call __init__
from my superclass Foo. Also __dict__ doesn't show an attribute
'bar':None so I guess Bar.__init__ is not called at all.

I would like to have a subclass with all attributes from superclasses
defined, and only the attribute from the first when there is conflict
(i.e. in this case, Foobar would be like this but with bar:None)

I tried this :

class Foobar(Foo,Bar):
def __init__(self):
Foo.__init__(self)
Bar.__init__(self)
defined by bar
{'x': 'defined by bar', 'foo': None, 'bar': None}

Here I have all I want, except the value of 'x' comes from the 'Bar'
superclass rather than Foo. So, to have what I want, I would have to
invert the two calls to __init__ in order to have the right x value.

What I find awkward here is that the order of __init__ calls matters,
rather than the order of the classes in the class declaration.

Do you have any ideas of a way to get this multiple inheritance thing
solved without having to do those __init__ calls ?


try:

class Foo(object):
def __init__(self):
super(Foo, self).__init__() # not really necessary here
self.x = "defined by foo"

class Bar(object):
def __init__(self):
super(Bar, self).__init__()
self.x = "defined by bar"

class FooBar(Foo, Bar):
def __init__(self):
super(FooBar, self).__init__()
and search for the "cooperative methods and super" section
in http://www.python.org/2.2/descrintro.html

Cheers,

SB


Thomas


Feb 15 '06 #2

P: n/a
Hi Thomas,

When an object is created, the __init__ function will be called. Since
you didn't define it in Foobar, the search path finds the __init__
function in Foo, so that's the one that is called. The second __init__
in Bar is masked since it comes second in the inheritance list..

If you want to call both constructors, then what you did is fine! The
fact that 'x' comes from the Bar object is ok too. That's what you told
python to do. What did you expect if you are setting 'x' twice? I mean,
when I type the following two statements into the interpreter:

a = 1
a = 2

then after those two statements execute, the value of a is
naturally 2, not 1. Same with your 'x'.

And what is wrong with the explicit calls to each constructor? After
all, in python, explicit is better than implicit. If you don't believe
me,
type "import this" in your interpreter:

import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Feb 15 '06 #3

P: n/a
Sébastien Boisgérault <Se*******************@gmail.com> wrote:
and search for the "cooperative methods and super" section
in http://www.python.org/2.2/descrintro.html


...., then read http://fuhm.org/super-harmful/ (not the evangelism, just
the examples) and
http://mail.python.org/pipermail/pyt...ry/050656.html .

When done, ask yourself if you need cooperative method calling or just
calls to the superclasses' __init__-functions. It's your call then,
because we don't know your use cases.

Cheers,
-jnf
Feb 16 '06 #4

P: n/a
thanks, you pointed exactly on what distrurbed me. I'll see what I can
do with cooperative methods.

Feb 16 '06 #5

P: n/a
That's perfect. thanks.

Feb 16 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.