[Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism
steve at pearwood.info
Fri Nov 17 00:52:52 EST 2017
On Thu, Nov 16, 2017 at 07:10:15PM +1300, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >These are not equivalent:
> >B < S, E
> >B < E, S
> Not in general, but in many cases they will be, e.g. if
> E and S have no method names in common. I think the OP is
> implying that his case is one of those.
Explicit is better than implicit :-) If Neil meant his suggestion to
only apply in the case where S and E have no methods in common, he
should have said so.
Given the possibility of __getattr__ or more exotic things like
metaclass trickery, we might not even be able to tell what methods are
possible. We'd need either some philosophy like "if you use this
feature, you're responsible for ensuring it works" (an excellent way to
guarantee hard-to-diagnose bugs in people's code *wink* ) or a more
complex set of requirements:
- none of the classes involved have a non-standard metaclass;
- none of them override __getattribute__ or __getattr__
- none of them have any methods in common
then, and only then, can Python attempt to reorder the MRO to suit.
Did I miss any necessary conditions?
But that seems like its adding a lot of complexity for little benefit.
Its not even clear whether this is practical -- why would the author of
class E specify __precedes__ to suit a class that they don't even know
exists? What if two classes both want E to specify the order in opposite
If I am the author of both E and B, then why don't I just reorder E's
superclasses directly, instead of using __precedes__?
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.
More information about the Python-ideas