[Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

Koos Zevenhoven k7hoven at gmail.com
Wed Nov 15 17:30:34 EST 2017

On Wed, Nov 15, 2017 at 11:49 PM, Neil Girdhar <mistersheik at gmail.com>

> Sometimes I get MRO failures when defining classes.  For example, if
> R < E, C
> B < S, E
> S < C
> Z < B, R
> Then Z cannot be instantiated because C precedes E in B and E precedes C
> in R.  The problem is that when the inheritance graph was
> topologically-sorted in B, the order was S, C, E.  It could just as easily
> have been S, E, C.  So, one solution is to add C explicitly to B's base
> class list, but this is annoying because B might not care about C (it's an
> implementation detail of S).  It also means that if the hierarchy changes,
> a lot of these added extra base classes need to be fixed.
> I propose adding a magic member to classes:
> __precedes__ that is a list of classes.  So, the fix for the above problem
> would be to define E as follows:
> class E:
>     from whatever import C
>     __precedes__ = [C]
> Then, when topologically-sorting (so-called linearizing) the ancestor
> classes, Python can try to ensure that E precedes C when defining B.
So it sounds like you are talking about the way that the siblings in the
inheritance tree (the bases of each class) get "flattened" into the mro in
a depth-first manner, and the relative order of siblings is not preserved.
What would you think about not topologically sorting the inheritance tree
as such, but sorting a graph that has additional edges according to the
base lists of each class involved? In this case those edges would be E->C,
S->E, B->R. Is this what your talking about, or do I misinterpret the

​​-- Koos

+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171116/ae10c5aa/attachment.html>

More information about the Python-ideas mailing list