On Mon, Nov 20, 2017 at 9:34 PM Nick Coghlan <ncogh...@gmail.com> wrote:
> On 21 November 2017 at 11:09, Neil Girdhar <mistersh...@gmail.com> wrote: > > > > On Sat, Nov 18, 2017 at 9:29 PM Nick Coghlan <ncogh...@gmail.com> 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 | 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/
