[Python-ideas] MRO local precedence ordering revisited

[Emanuel Barry]

I wholeheartedly agree with Chris on this one. This isn't broken, nor is it something we want to change. If you're looking for a case where object is not the last of its hierarchy, Python 2 has classic classes, but they are remaining artefacts there. The MRO needs to be consistent across all classes along the MRO, with object last.

> Date: Fri, 11 Dec 2015 04:29:05 +1100
> From: rosuav at gmail.com
> CC: python-ideas at python.org
> Subject: Re: [Python-ideas] MRO local precedence ordering revisited
> 
> On Fri, Dec 11, 2015 at 3:36 AM, Stephan Sahm <Stephan.Sahm at gmx.de> wrote:
> > 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.
> 
> Just to make something quite clear: "current" Python, as discussed on
> this list, is 3.5 or 3.6, not 2.7. There won't be a 2.8, and future
> releases of 2.7.x won't be changing anything like this. What you're
> describing is also the case in current Python 3.x, but any change to
> how the MRO is derived would happen in 3.6 at the very soonest. (At
> least, I don't _think_ the current behaviour could be considered a
> bug. I could be wrong.)
> 
> > 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):
> >
> > [quoting the docs]
> >> 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).
> >
> > 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.
> > (I myself want for instance a Mixin to overwrite the __init__ method, which
> > is simply not impossible when choosing class B(A, Mixin))
> 
> What you're proposing, in effect, is that it should be possible for
> super() to go *down* the class hierarchy. Under your proposal,
> B.__mro__ would be (Mixin,A,object), which means that super().method()
> inside A will go directly to object, and that the same call inside
> Mixin will go to A - reversing the order of the calls compared to the
> way they would be if the object were of type A. Now it is known that
> the super doesn't mean "call my base class", but something more like
> "call the next class"; but it's currently guaranteed that the MRO for
> any derived class is a *merge* of the MROs of its parents, without
> ever reordering them. Under your rules, what would be the MRO here?
> 
> class A(object): # explicitly stating the default
>     def __new__(cls):
>         print("Constructing an A")
>         return super().__new__(cls)
>     def method(self):
>         print("Calling method on A")
>         super().method()
> 
> class B(object, A):
>     pass
> 
> If you answered (B,object,A), then you've just made it possible to
> have some other class than object at the end of the chain. Where do
> super() calls go if there *is no next class*? What should happen? Can
> that be made equally intuitive to your proposal about mixins?
> 
> ChrisA
> _______________________________________________
> 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/6aa42f1d/attachment.html>