Needed: Real-world examples for Python's Cooperative Multiple Inheritance

[Steven D'Aprano]

On Fri, 26 Nov 2010 23:24:30 -0800, John Nagle wrote:
> On 11/26/2010 4:21 PM, Mark Wooding wrote:
[...]
>>> @This catches the case where two classed both inherit from, say
>>> "threading.thread", each expecting to have a private thread.
>>
>> Why on earth would anyone do such a bizarre thing?  If you want a
>> private thread, then attach one as an attribute.  Inheriting is simply
>> madness.
> 
>     This must be from someone who hasn't used threads in Python.
> 
>     The usual way to write a thread in Python is to subclass
> "threading.thread".  The subclass provides a "run" function, which will
> be called from the new thread.

Wanting a private thread, and writing a thread, are not the same. Of 
course you have to subclass threading.thread to write a thread. But if 
you want a private thread, there's no need to subclass thread just to get 
one. You would add a thread as an attribute, exactly as you would add a 
list or a dict or an int as an attribute if you wanted a private list or 
dict or int. Trying to juggle access from *multiple* classes to a 
*private* thread doesn't seem sensible, which was Mark's point.



>> If you
>> stopped whining about how Python's object system might theoretically go
>> wrong if you try to use it like it was C++ and started thinking about
>> how to actually make effective use of the features it offers --
>> features which long predate Python, and have been thought about over
>> many years, in languages such as Zetalisp, Common Lisp, Dylan, Scheme,
>> and variants of Smalltalk -- you might got on much better.
> 
>     Ah, fanboys.
> 
>     Of those, I've written code in Common Lisp, Scheme, and Smalltalk.
> Most of the LISP variants really did objects very well; objects were an
> afterthought.

Describing something as an afterthought is normally meant as a 
pejorative. To say that Lisp "really did objects very well" *and* that 
they were afterthoughts seems like a contradiction.



> Smalltalk went a bit too far in the other direction; the
> "everything is an object" mindset was overdoing it.
> 
>     Python is reasonably well balanced in the object area.
> Everything isn't an object.

I don't understand what you mean by this. Can you give an example of a 
thing in Python that is not an object?



> There are explicit classes, unlike the
> instance-copying model of Self and Javascript.  However, multiple
> inheritance is something of a mess, as the original starter of this
> thread found when he tried to document how to use it.
> 
>     If you have real trouble writing documentation for a feature, it's
> usually because the feature is badly designed.

The problem isn't writing documentation for the feature, but coming up 
with real-world use-cases. The documentation for super and the MRO is 
extensive and detailed. It's also complicated, because multiple 
inheritance is complicated. But it seems that multiple inheritance might 
not be that useful outside of a small number of cases.


-- 
Steven