Real Problems with Python

[Neel Krishnaswami]

Justus Pendleton <justus at my-deja.com> wrote:
> In article <slrn8aec0e.lqg.neelk at brick.cswv.com>,
>   neelk at alum.mit.edu wrote:
> > > > 3. Multiple inheritance is unsound
> > > >
> > > >  By 'unsound' I mean that a method call to a method inherited by
> > > >  a subclass of two other classes can fail, even if that method
> > > >  call would work on an instance of the base class.
> 
> In an earlier post you mentioned that Dylan gets this "right" but as I
> understand it, in Dylan two classes with the same getter generic
> function ("x" in this case) are "disjoint - they can never have a common
> subclass and no object can be an instance of both classes" (from the
> Dylan Reference Manual section on Slot Inheritance).  It seems like
> Dylan resolves this by simply saying you can't write code like that, not
> by making Multiple Inheritance safer.  Or am I missing something?

No, not at all. Dylan makes MI safe by not letting you use it in
unsound ways. There's a moral here, but I'll leave it for the end of
the post. :)

Michael Hudson posted an Eiffel sample, and pointed out that they use
feature renaming to deal with the name conflict problem. However, this
is not something that works really cleanly in a language as dynamic as
Python -- to raise the appropriate exception when an ambiguous name is
added to a class dictionary would involve scanning the class hierarchy
both up and down for every new name. (It still might be the right
solution, depending on where you put the balance between simplicity of
implementation and safety for the user.)

So I looked at some other dynamic languages to see what they did.

o Dylan -- forbids using MI when there are multiple slots with the 
  same name.

o Cecil -- same as Dylan, more or less. It complains when you inherit
  multiple fields with the same name.

o Smalltalk/Self/Ruby -- only allow single inheritance, so the
  problem just doesn't arise. 

o Oaklisp -- uses exactly the same rule as Python, and ignores the
  problem of soundness just like Python does.

o PLT Scheme -- only allows single inheritance of implementation, and
  MI of interface a la Java, so that ambiguities can be detected and
  complained about.

o Common Lisp -- has a linearization rule that is more complicated
  than Python's but still unsound.

Other languages seem to either forbid name conflicts or just suck it
up and live with an unsafe rule, which leads me to conclude that the
moral is TANSTAAFL -- there ain't no such thing as a free lunch.


Neel