On Apr 11, 12:09 pm, Steve Holden <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
