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 directions? 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. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
