Dear all, this is a highly sensitive topic, isn't it? =) Thank you all for your extensive responses. Of course I was a bit provocative with the sentence in bold, but I haven't said this would be a bug, and if I have, I am sorry for that. I am in fact not familiar with what precisely are all the problems the C3 algorithm tries to solve, however my own intuitiv MRO would not be anything proposed so far, but: (B, mixin, A, mixin, object) or in the simpler, more trivial version (B, object, A, object) As you haven't mentioned this as a possibility at all, I guess having a class twice in this list produces some weird behaviour I do not know about yet - if someone can point out, that would be great. cheers, Stephan P.S.: I haven't said that I want a python 2.8, nevertheless thanks for pointing out that there won't be a python 2.8 (this I in fact have not known before)! I am familar with python 3.5 as well, however I just wanted to make clear where I am working and in which language the example code is runnable. On 10 December 2015 at 19:58, Andrew Barnert <abarnert@yahoo.com> wrote:
On Dec 10, 2015, at 08:36, Stephan Sahm <Stephan.Sahm@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 attribute s 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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/