[Python-ideas] Is multiple inheritance Pythonic?

[Martin Teichmann]

Hi Andrew, Hi List,

> So, what _are_ the reasons inheritance isn't the best way to handle this kind of customization? The two most famous are:

thanks, that was a interesting read. Hopefully not just for me but
also for others.

I still have to let that sink in: inheritance, even multiple is fine,
just not across a
framework boundary, because you never know how the user is overriding the
methods. For me, coming from a GUI background (Qt, that is) that's
still astonishing, as there inherit-and-override is a concept used very often,
especially across the framework boundary.

> 1. With subclassing-for-specialization, it's rarely clear--even in a language like C++ where the required protected and virtual act as markers, much less in Python--which methods you are expected to override.

In the GUI world, that's simply solved by documentation. Qt, and also
PyQt, document very precisely
which methods are supposed to be overridden, and how.

And I still like that concept, as it has a lot of flexibility. You may
call super(), or not, depending on
what you want to do, even overriding a method several times in the
inhertance chain is not uncommon,
even across framework boundaries. With set_task_factory, I'm still
trying to figure out how to call
the base implementation, as super() won't do it. (Thats another topic,
but if someone could tell
me I would be really happy. I simply want to keep track of all created
tasks, so I would simply
love to call super().create_task(), log the created task and I'm done.
No I cannot use Task(), as
I don't know whether the EventLoop actually uses that.)

> The general trend here is easier to see (and therefore so are the motivations behind it) in the brace-family languages. Unlike Python, which has always[5] treated classes and methods and everything else as first-class objects, they have to invent a whole new language feature (first interfaces, then delegates/method-pointers, then event-handlers) at each step, which usually means a whole new language and stdlib. Fortunately, when people figure out a better way of doing things in Python, we can just gradually start using the better way in place of the old way.

What do you mean with the last sentence, what is that better way?
Having a set_whatever_factory
instead of inheritance, is that what you mean?

Thanks for the enlightening post

Martin