[Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism
k7hoven at gmail.com
Thu Nov 16 07:06:29 EST 2017
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>
>>> 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
> 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 yet 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 Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas