MRO theory

[Clarence]

On Apr 11, 5:21 pm, "Carl Banks" <pavlovevide... at gmail.com> wrote:

> > 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.
>
> It *might* not be an accident.
Actually, what I meant to write was that my sorting was done by
accident, but the heart of my question is, *was* it an accident? I
don't have enough theory to answer that question.

>
> Because Java interfaces can be listed in any order, it's quite
> possible that some interface hierarchies in Java violate Python's MRO
> restrictions right out of the box.  I would guess that JPype deals
> with this situation by applying a consistent ordering to of bases when
> it creates a proxy class.  And it just might turn out that "order of
> creation" is the sort key.  Or something else could be the key
> (alphabetical by name?).  Regardless, sorted order just *might* be the
> proper order to list bases to ensure MRO consistency.
>
> I'd suggest that this is probably a question better answered on the
> JPype mailing list, since they would have answers and not just
> speculations.

It's a theoretical question, and Python implements the theory. And no,
JPype does not deal with it at all; that's what I'm trying to fix.

I know sorting by name does not work because that's one of the things
I tried. You can start out with sorted base class lists, but the
merging
involved in creating the mro of a new class destroys that ordering. I
find it very reasonable, however, to think that the creation order of
the classes (implying constraints on the possible superclass
relationships)
may well be a property that the merge will always leave untouched.

Hence my question.