On Mon, Nov 20, 2017 at 9:41 PM Nick Coghlan
On 21 November 2017 at 12:34, Nick Coghlan
wrote: 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 ... >>>
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)"), 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 do wonder if we might be able to make the error message here less cryptic by mentioning which *listed* base classes brought in the conflicting MRO entries.
Consider the current:
>>> class Z(B, R): 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
vs something like:
TypeError: Cannot create a consistent method resolution order (MRO) for bases C, E (inherited through B, R)
(Note: I haven't actually checked how practical it would be to implement something like that)
I totally agree. I actually proposed this on ideas a few months ago and then wrote something here: https://github.com/NeilGirdhar/inheritance_graph If you have any suggestions or improvements, please feel free to improve the code. Best, Neil
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia