multiple inheritance super()

[Mike Meyer]

"Michele Simionato" <michele.simionato at gmail.com> writes:
> Mike Meyer:
>> I think you're replying to me, but you didn't include any indication
>> so I can't be sure.
>
> Oops, sorry, yes, I was replying to you.
>
>> These two are cases of what I was talking about when I referred to the
>> Church-Turing thesis.
>
> Well, let me put it in this way. If a language can implement a
> missing feature easily, then you are not really missing a big thing.
> And the feature may not be provided by default for sake of semplicity
> and/or uniformity of style. For instance Python does not have
> repeat-until
> loops, case statement, ternary operator, etc. (obviously I am not
> advocating to remove multiple inheritance now, I am justing
> speculating, talking about an hypotetic new Python-like language).
>
>> Also, I don't see how they make the situation
>> you are scared of above any better.
>
> It would discourage some people from some abuses, in the same sense the
> absence of repeat-until, case statemente, ternary operator etc are
> working right now.

These two points are working at cross purposes. If you can implement a
missing feature easily, then it doesn't do much to discourage abuses
of that feature.

>> > 3. think differently and use multimethods
>>
>> I don't see how that would help at all. You haven't done anything
>> about solving the base problem - that getting the methods into my
>> classes cleanly needs multiple inheritance. Further, I don't need
>> methods that are distinguished based on their arguments - they all
>> take a fixed set of arguments, and operate on them and the state of
>> the instance. None seem to be candidates for being multimethods. The
>> mixin methods tend to provide general functionality, and get used in
>> radically different places by the different child classes.
>>
>> You did miss the one alternative I considered: making the methods of
>> Mixin stand-alone functions, and passing them extra arguments instead
>> of using attributes of the instance. They would all then look like
>> mixin_func(self.foo, self.bar, var, value). I decided that this wasn't
>> as readable as inherting the methods.
>
> Uhm? I do not follow you. Multimethods would dispatch according
> to the type and would act differently on the childrens, dependending
> on their state. Perhaps I would need more information to understand
> what
> you have in mind.

Ok, let's take a typical Mixin example. All the classes work with HTML
pages rendered as soup. Some of them only deal with one page, others
walk through multiple pages to find some specific bit of
information. Each of them stores the page it's currently working on in
the attribute page.

The get_value method of Mixin extracts a string from self.page. You
pass it a string, it invokes methods of self.page to locate a string
that stands in a fixed relation to the string you passed in to it, and
returns the found string.

I don't see how this could be made a multimethod. What it does doesn't
change depending on selfs type. This example could trivially have been
done as a standalone function, as it only uses one attribute. Others
use more, say filling out forms based on a dictionary attribute, or
some such.

> But at the end my point is "I would not feel much more constrained
> in expressivity if I did not have multiple inheritance in Python,
> and actually I have found out that the more I use OOP, the less I
> use inheritance".
>
> Just curious if others had a similar experience.

No, and yes. I think that using less inheritance as you get more
practice with it is a common thing. At first, it seems very cool, and
you're tempted to use it for everything. Then you find the problems
that this creates, and back off from it some. On the other hand, as my
understanding of inheritance deepened, I found myself using multiple
inheritance more, not less. Mostly, it's for mixins. Sometimes, I
really do need objects that have multiple types.

       <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.