On Tue, 29 Mar 2022 at 06:12, malmiteria <martin.mi...@ensc.fr> wrote:
>
> Steven D'Aprano writes:
>
> > How else are you going to get inheritance without a linear order? The
> > interpreter can only call superclass methods one at a time, in
> > some linear order.
>
> You can decide what method should be the one resolved to *after* visiting all
> superclass methods.
>
> I've already implemented it here, it's a "simple" recursion (no recursion is
> ever simple xD):
> https://github.com/malmiteria/super-alternative-to-super/blob/59ff90029db6e4b63fb72bd807e694e9de9514e8/parent.py#L43
>
Lots of checking of __dict__ here - what happens if it has __slots__?
> Essentially, as long as parent don't have it, you keep looking higher in the
> inheritance tree, either you find no such method, and you raise an
> AttributeError, if you found it only once, you return it, and if you found
> multiple, you raise the ExplicitResolutionRequired error.
>
> The order in which you visited the parent is irrelevant to the result, what
> matters is only to stop exploring a branch when it ends, or when you found
> the method. Each parent is looked up in its own branch, independantly of any
> other branches.
>
> The end result is absolutely not affected by the order in which you've
> explored those branches
Okay, this is definitely looking like what I was saying about a pizza
inheriting from its crust and toppings.
If I'm reading this correctly, you're defining a "conflict" as finding
two implementations of the same-named method in independent subtrees
of inheritance - that is, when you say "class Pizza(Crust, Topping):",
you're treating Crust and Topping as completely independent, and if
they both define an add_cheese method, that's a conflict.
That's not inheritance. That's composition.
> > The whole point of inheritance is that (to the degree that it is
> possible) we should not explicitly care about where the methods are
> defined
>
> Agreed. My solution doesn't require you to be explicit about where a method
> is defined.
> It only eventually raises an error in case of collision, which you can
> resolve by redefining the method in the child class, only if you intend on
> calling it (not calling a method that would raise an error is fine with my
> solution, whereas current MRO + super fails at class definition time no
> matter your use of that class).
> my __as_parent__ allows to explicitely call each one of the parents method
> individually wherever it matters to you
>
> --
> > If you do want to explicitly specify where the methods are defined
>
> I don't, at least that's not what my solution is for / requires you to do.
>
> --
> > If you want to manage your "inheritance" manually by specifying the
> > order, then just don't use automatic inheritance
>
> That's what i have to resolve to today yeah. The feature has its limits,
> working around it is painful, that's why i'm proposing this change to the
> language
If you want to make a semi-cooperative way to look up methods in
either of several components, I'd look at something like this:
@pass_along
class Pizza:
__components__ = Crust, Topping
where the pass_along decorator adds a __getattr__ method that
basically goes "does this component have it? does this component have
it?" and then resolves conflicts accordingly. That way, external
callers can refer to Pizza methods as if they are the union of all
Crust and Topping methods, but without the issues of confusing
behaviour that changing the definition of inheritance gives.
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VILJ2Y6MOLCGADTMHE7JY7VQUJK5EKRE/
Code of Conduct: http://python.org/psf/codeofconduct/
