On 18 November 2017 at 09:03, Neil Girdhar <mistersh...@gmail.com> wrote: > On Fri, Nov 17, 2017 at 3:15 AM Nick Coghlan <ncogh...@gmail.com> wrote: >> I'll note that an interesting side effect of >> https://www.python.org/dev/peps/pep-0560/#mro-entries will be to allow >> folks to write: >> >> class MyCustomMRO: >> def __init__(self, *bases): >> self._resolved_bases = my_mro_resolver(bases) >> def __mro_entries(self, orig_bases): >> if len(orig_bases) > 1 or orig_bases[0] is not self: >> raise TypeError("CustomMRO instance must be sole base >> class") >> return self._resolved_bases >> >> >> class Z(MyCustomMRO(B, R)): >> ... >> >> The custom MRO algorithm may then allow for use case specific hints to >> handle situations that the default C3 resolver will reject as >> inconsistent or ambiguous. (I'll also note that such a custom resolver >> would be able to manufacture and inject synthetic metaclasses if >> that's what someone decided they really wanted to do, by also >> synthesising a custom base class to stick at the head of the list of >> bases). > > This is really cool!
Unfortunately, as Koos noted, it doesn't actually work as simply as I presented it: even if you spell out a full MRO in the most-derived class, the C3 resolution algorithm will complain that it's inconsistent with the order in one of the two conflicting base classes. So to truly get a custom method resolution order, you're likely going to end up needing a custom metaclass involved. 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/