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

[Koos Zevenhoven]

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

> 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
problem?

​​-- 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>