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

[Koos Zevenhoven]

On Thu, Nov 16, 2017 at 5:28 AM, Neil Girdhar <mistersheik at gmail.com> wrote:

> On Wednesday, November 15, 2017 at 5:32:00 PM UTC-5, Koos Zevenhoven wrote:
>>
>> On Wed, Nov 15, 2017 at 11:49 PM, Neil Girdhar <miste... 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.
>>
>
> It is preserved, but there are insufficient constraints, which causes
> problems with future class definitions.
>
>
>> 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?
>>
>
> That's already part of the topological sorting algorithm.  You have to do
> that.  I'm suggesting additional constraints.
>
>

​​I'm talking about the initial graph to be sorted. Not some intermediate
graph that may be used for describing steps in an algorithm.

Anyway, the contraint given by the edge E->C is not y​et part of the
algorithm, because if it was already there, you wouldn't need
"__precedes__" to add that edge.

But another thing that affects this is whether we consider multiple
occurrences of a class in the inheritance tree as the same node in the
inheritance graph or not. If yes, then the inheritance tree and the
inheritance graph are two different things.

––Koos

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