On 21 November 2017 at 12:34, Nick Coghlan <ncogh...@gmail.com> 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)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
