[Python-ideas] MRO local precedence ordering revisited

Thu Dec 10 13:58:30 EST 2015

On Dec 10, 2015, at 08:36, Stephan Sahm <Stephan.Sahm at gmx.de> wrote:
> 
> Dear all,
> 
> I just pushed a very specific question which as I now recognized is far more general: It concerns python MRO (method resolution order).
> 
> As reference I take https://www.python.org/download/releases/2.3/mro/
> There the section "Bad Method Resolution Orders" starts with an example which behaviour in the current python 2.7 is rather unintuitive to me.

First off, Python 2.7 isn't going to change, and there isn't going to be a 2.8. If you want to propose changes to Python, you first need to learn what's changed up to 3.5, and then propose your change for 3.6.

Second, the fact that it's unintuitive may be a problem with the description, rather than the algorithm. Once you understand what it's trying to do, and what you're trying to do, and why they're not compatible, it's intuitive that it doesn't work. Maybe the docs need to make it easier to understand what it's trying to do, and maybe you can help point out what's confusing you.

Since Python just borrowed the C3 algorithm from Dylan to solve the same problems, and other languages have borrowed it as well, you might want to search for more generic documentation on it, too.

Anyway, if you understand what C3 is solving, and you think it could be modified to still solve those problems while also allowing your use, or that one of those problems can't be solved but you don't think it's actually a problem, then explain that. Otherwise, I think you're either asking for something inconsistent, or asking for something consistent but broken, like the C++ rules (which would be even more broken in Python without first adding notions like virtual base class and auto-pre-supering constructors).

> I rename the example slightly to illustrate its usecase.
> 
>> class Mixin(object):
>>     pass  
>> class A(Mixin):
>>     pass
>> class B(Mixin, A):
>>    pass
> 
> this unfortunately throws "TypeError: Error when calling the metaclass bases Cannot create a consistent method resolution order (MRO) for bases A, Mixin"
> 
> 
> The reference name above comments this case similar to the following (adapted to the easier example above):
>> We see that class B inherits from Mixin and A, with Mixin before A: therefore we would expect attributes of B to be inherited first by Mixin and then by A: nevertheless Python 2.2 was giving the opposite behaviour.
>> ...
>> As a general rule, hierarchies such as the previous one should be avoided, since it is unclear if Mixin should override A or viceversa
>  
> 
> While it might be the case that in Python 2.2 things where different, I cannot agree that the expected order of Method resolution is ambiguous (at least as far I see at this stage).

Mixin has to appear before A so that its methods appear before A's. But Mixin has to appear between A and object so that A's methods can count on inheriting from it. How do you fit both those constraints?

> The reference itself says that we would expect B to be inherited first by Mixin and then by A. There is no ambiguity any longer.
> 
> Therefore I would like to propose to make this MRO again a valid one.
> 
> 
> The usecase should be obvious: If you want a Mixin to be the first thing overwriting functions, but still want to inherit as normal.

That's not what mixins are for. Mixins add behavior; something that changes the behavior of a real superclass is something different.

> (I myself want for instance a Mixin to overwrite the __init__ method, which is simply not impossible when choosing class B(A, Mixin))
> 
> 
> best,
> Stephan
> 
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151210/f0d8d041/attachment.html>