On Mon, Nov 20, 2017 at 9:34 PM Nick Coghlan
On 21 November 2017 at 11:09, Neil Girdhar
wrote: On Sat, Nov 18, 2017 at 9:29 PM Nick Coghlan
wrote: >>> class C: pass ... >>> class S(C): pass ... >>> class E: pass ... >>> class B(S, E): pass ... >>> class R(E, C): pass ... >>> class Z(B, S, R, E, C): pass ... Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Cannot create a consistent method resolution order (MRO) for bases C, E
Sorry, I wrote back too quickly. I meant also to change B's requested MRO to be:
(B, S, E, C)
It works with that change.
Right, but once you do that, then the existing resolver is already able to handle things:
>>> class C: pass ... >>> class S(C): pass ... >>> class E: pass ... >>> class B(S, E, C): pass ... >>> class R(E, C): pass ... >>> class Z(B, R): pass ... >>>
Sure, but like I mentioned, that's really ugly because B doesn't care about C and shouldn't have to mention it as a base class. This solution can quickly spiral out of control so that changes in the inheritance graph require you to hunt down extraneous base classes.
If you wanted to pick up cases where two classes generate inconsistent MROs that will prevent mutual subclasses (like "class B(S, E)" vs "class R(E, C)"),
yes, exactly.
that feels like a job for a type checker, since it isn't obvious whether it's the definition of B or the definition of R that should be changed to reorder their MRO.
I don't know what the "type checker" means here. I figured that the easiest user specification would be precedence relationships between classes that could be applied (in the way I described). And I figured that that could be processed for given classes when their MRO is generated. The proposal of having a custom MRO generator would also be able to solve this problem.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia