If you're short on time, the subject's all you need to read. It seems
like it would always be the right thing to do, when the sub-class
specifically requests it.
It's very unlikely that multiple inheritance would go horribly wrong, as
long as classes adopt class-specific argument naming conventions.
However, ever since bug 1683368 [0] was fixed, it's now impossible to
cleanly create arbitrary inheritance trees. The only reason I can't
just take anybody's code and plop it into my inheritance tree is because
Python demands that each class specifically opts in to MI though
mechanisms like the following:
1: class Foo(object):
2: def __init__(self, foo_bar, *args, **kwargs):
3: if Foo.__mro__[1] != object:
4: super().__init__(*args, **kwargs)
5:
6: self.bar = foo_bar
Lines 3 and 4 are required because Foo might fall at the beginning or
the middle of in the inheritance tree: we can't know ahead of time.
>From my perspective, it'd be lovely if init methods implicitly accepted
*args and **kwargs while implicitly sending them off to the next class
in the MRO as the first call. This would make the previous example
semantically equivalent to:
1: class Foo(object):
2: def __init__(self, foo_bar):
3: self.bar = foo_bar
Granted, that's probably too excessive and implicit for most folks to be
comfortable with, even though that's obviously the behavior a user
intends when they write code like:
1: class Baz(Foo, Bar):
2: def __init__(self):
3: super().__init__(foo_bar=1, bar_quote="Give me another!")
Fundamentally, I don't care if Foo or Bar explicitly handle being
composed into the inheritance tree. They can be composed correctly
(they can do what the user is asking) in most obvious and simple cases,
and it'd be fine by me even if we threw errors in complex situations
(like overlapping argument names in init methods).
So, would it be a good idea to:
1. Undo the fix to bug 1683368, making multiple inheritance easier?
2. Make MI implicit, when subclasses try to use it?
Thanks for your time,
Nick
0: http://bugs.python.org/issue1683368
--
http://mail.python.org/mailman/listinfo/python-list
