Real Problems with Python

[Charles Hixson]

Well, in Eiffel one would need to declare the inheritance pattern to by used by x
wouldn't you?  Where Python doesn't have declarations of variables.  I suppose that
one could interpolate a rule that said something like:
"The value of a variable inherited from more than one ancestor class must be
prefixed by the name of the class from which it was inherited."
Which shouldn't break any code that was currently safe.  The other alternative would
be to require that those variables be renamed (in essence, the Eiffel solution) ..
Thus:
for Foo.x use fooX
for Bar.x use barX
etc.

Neither solution seems to fit *really* nicely into Python.  Neither clashes very
badly.  My personal preference is the renaming solution, because otherwise
occasionally names will grow too long to be convenient.  But it doesn't seem a
difficult problem, merely a real one.

Michael Hudson wrote:

> neelk at brick.cswv.com (Neel Krishnaswami) writes:
>
> > > > 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.
> > >
> > > Unsure what this is about; am pretty sure nobody has complained about it
> > > before.  Certainly "depth first, left to right" is an unprincipled approach,
> > > but in practice it's more than predictable enough to use.
> >
> > Here's some code:
> >
> > class Foo:
> >    x = 99
> >    def frob(self):
> >        print "%d bottles of beer" % self.x
> >
> > class Bar:
> >    x = "bar"
> >    def wibble(self):
> >        print "Belly up to the " + self.x
> >
> > Note that all the operations on Foo and Bar work safely for direct
> > instances of Foo and Bar.  But if you define a subclass like so:
> >
> > class Baz(Bar, Foo):
> >    pass
> >
> > you can get type errors even though both of the superclasses have
> > type-safe operations:
> >
> > >>> q = Baz()
> > >>> q.frob()
> > Traceback (innermost last):
> >   [...]
> > TypeError: illegal argument type for built-in operation
> >
> > This is only an annoyance in day-to-day work, but it becomes a big
> > problem if you are serious about building automatic code analysis
> > tools for Python (eg for CP4E). This is because the soundness theorems
> > needed to write things like soft typing tools no longer hold. :(
>
> How is this different from (excuse the dodgy syntax, I haven't done
> much Eiffel):
>
> class FOO
>    feature
>       x: INTEGER
>
>    feature frob: STRING is
>       do
>           Result = interpolate("%d bottles of beer",x.to_string)
>       end
> end
>
> class BAR
>    feature
>       x: STRING
>
>    feature wibble: STRING is
>       do
>           Result = concatenate("Belly up to the ",x)
>       end
> end
>
> class BAZ
>     inherit FOO,BAR
> end
>
> ? I mean, that won't compile, presumably, but in the case of a code
> analysis tool there comes a point when it can just throw it's hands up
> in the air and say "you're not playing by the rules, I give
> up". Repeasted feature inheritance is not a solved problem in any
> language I'm aware of.
>
> And in this case, the code has a bug, so code analysis catching it is
> surely a good thing?
>
> not-at-understanding-yet-ly y'rs
> Michael