On Mon, Nov 20, 2017 at 9:41 PM Nick Coghlan <[email protected]> wrote:
> On 21 November 2017 at 12:34, Nick Coghlan <[email protected]> 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 | [email protected] | Brisbane, Australia >
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
