On 17 November 2017 at 15:52, Steven D'Aprano <st...@pearwood.info> wrote: > There's a lot of benefit to having a relatively simple, understandable > algorithm for determining the MRO, as opposed to some sort of adaptive > rule that will try to reorder classes according to potentially clashing > constraints. If that means that some classes cannot go together in > multiple inheritence because their MRO would be inconsistent, I think > that's a price worth paying for not having to debug inheritence bugs > caused by weirdly reordered MROs.
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). 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/