<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Fri, Nov 17, 2017 at 10:14 AM, Nick Coghlan </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 17 November 2017 at 15:52, Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br>
> There's a lot of benefit to having a relatively simple, understandable<br>
> algorithm for determining the MRO, as opposed to some sort of adaptive<br>
> rule that will try to reorder classes according to potentially clashing<br>
> constraints. If that means that some classes cannot go together in<br>
> multiple inheritence because their MRO would be inconsistent, I think<br>
> that's a price worth paying for not having to debug inheritence bugs<br>
> caused by weirdly reordered MROs.<br>
<br>
</span>I'll note that an interesting side effect of<br>
<a href="https://www.python.org/dev/peps/pep-0560/#mro-entries" rel="noreferrer" target="_blank">https://www.python.org/dev/<wbr>peps/pep-0560/#mro-entries</a> will be to allow<br>
folks to write:<br>
<br>
    class MyCustomMRO:<br>
        def __init__(self, *bases):<br>
            self._resolved_bases = my_mro_resolver(bases)<br>
        def __mro_entries(self, orig_bases):<br>
            if len(orig_bases) > 1 or orig_bases[0] is not self:<br>
                raise TypeError("CustomMRO instance must be sole base class")<br>
            return self._resolved_bases<br>
<br>
<br>
    class Z(MyCustomMRO(B, R)):<br>
        ...<br>
<br>
The custom MRO algorithm may then allow for use case specific hints to<br>
handle situations that the default C3 resolver will reject as<br>
inconsistent or ambiguous. (I'll also note that such a custom resolver<br>
would be able to manufacture and inject synthetic metaclasses if<br>
that's what someone decided they really wanted to do, by also<br>
synthesising a custom base class to stick at the head of the list of<br>
bases).<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​I can imagine someone wanting that, but it still doesn't allow customizing the *whole* MRO, AFAICT. Regarding the inheritance trees of B and R that is. Or at least trying to somehow achieve that without introducing a metaclass would probably become a terrible hack (if not just impossible).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div><div class="gmail_default" style="font-family:monospace,monospace">​</div><br></div><div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>