MRO theory

[Clarence]

On Apr 11, 12:09 pm, Steve Holden <s... at holdenweb.com> wrote:
> Without wishing to lay claim to genius, I'd suggest that you don;'t
> write programs relying on multiple inheritance until you have a thorough
> understanding of its principles.
>
> The inability of the interpreter to create a consistent mro has nothing
> to do with the order in which the base classes were created or where
> they appear in memory. It's probably because you have introduced a
> circularity: you are trying to define something based on A, which is
> based on B, which is based on A or something similar.
>

No, there is no circularity. The problem is coming about in the JPype
application. It creates a Python class to proxy any Java class or Java
interface that the program uses (directly or indirectly). As far as
the
Java proxies go, when it creates a class it can have at most one
superclass
that is a proxy of a Java class, and arbitrarily many superclasses
which
are proxies of Java interfaces.

The problem basically comes about because interfaces are not classes,
but a class is being created to stand in for each one.

There is real Java code that is causing a class construction failure
because of an inability to construct a consistent mro. I've tried
several
approaches to make it work, and by accident, sorting the list of
interface
proxy classes, using the default comparison, make it work. That made
me
wonder if the theory had something to say. Obviously, if class A is
created
before class B, then B cannot be a base class of A, hence the
chronological
order of class creation _might_ have something to do with creating
acceptable
or unacceptable mro's.