[Python-ideas] MRO local precedence ordering revisited

[Stephan Sahm]

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 at yahoo.com> wrote:

> 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 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 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/e32bbc42/attachment-0001.html>