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

[John Nagle]

On 11/26/2010 4:21 PM, Mark Wooding wrote:
> John Nagle<nagle at animats.com>  writes:
>
>> I'd argue that a better implementation would require that when there's
>> a name clash, you have to specify the class containing the name. In
>> other words, if A is a subclass of B, then B.foo() overrides
>> A.foo().  But if C is a subclass of A and B, and there's an A.foo() and
>> a B.foo(), calling self.foo() in C should be an error, because it's
>> ambiguous. You should have to specify the parent class, using "super".
>
> How peculiar.  `super' is /specifically/ for working out dynamically
> which superclass to delegate behaviour to, because working it out
> statically isn't possible in general.
>
>> The same issue applies in the other direction.  If A and B are
>> subclasses of D, and A.foo() and B.foo() are defined, and D calls
>> self.foo(), that's an ambiguity and should be reported.
>
> No it isn't.  It's downward delegation, which is an essential feature of
> object oriented design.
>
>> @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.

> 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.  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.  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.

				John Nagle