[Python-ideas] Re: mro and super don't feel so pythonic
Greg Ewing writes: > On 16/04/22 10:46 pm, Steven D'Aprano wrote: > > There is no *guessing* in the C3 linearization algorithm. > > "Guessing" in the context of that Zen line means making an arbitrary > choice that may or may not be what the programmer wants. It doesn't > mean choosing at random. Every feature means making an arbitrary choice that may or may not be what the programmers wanted. That's why we sometimes rewrite stuff in C: because most applications of "such stuff" we want time or space performance more than we want the dynamic power of Python. But we have a requirement (at least a strong suggestion) that where possible C modules should also provide Python implementations so that people who want the power of Python can have it, at some cost in performance. So in the context of the Zen, I suggest we "refuse to guess" *because* that arbitrary choice also forecloses (or at least makes very difficult) other choices. Otherwise, that Zen would discourage adding any features at all! But to me, C3 is hardly arbitrary. The technical sense in which a deterministic algorithm doesn't guess is irrelevant to the Zen, as you point out. But I don't think that's what Steven meant. Someone wrote that C3 is based on 5 requirements, which could also be considered assumptions about what the programmer wants. I don't recall what they are exactly, but they seemed really plausible to me as a guide to what most programmers would want, or at least find acceptable, most of the time. If you're going to call something even in the event of multiple definitions, C3 has benefits (I don't have time to enumerate them right now). I don't think that's an arbitrary guess, and I think that's what Steven meant. But still, what if that's not what the programmer wants? Can they get what they want, *as easily as if the feature didn't exist*? How often does it happen that they can't? I haven't seen any compelling answers to those questions, only cooked-up toy programs whose only known use is to give the answer "yes" to the question "can I find a program where super() and/or C3 can't do the thing I arbitrarily prespecify that the program must do?", and one (1) hearsay story whose "harm" is perfectly well redressed by "OK, don't fix what ain't broke, then". Steve ___ 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/63GGODAVSDZKSNK33SXYZZQFFLN7HY3F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
I'm a bit late to this conversation, but here i go: Steven d'Aprano writes: > But given the assumptions that: > > - the inheritance model automatically resolves conflicts; > > - the MRO is entirely dependendent on the shape of the inheritance > graph, and not on incidental properties like the name of classes; > > - the inheritance model is consistent, monotonic and preserves local > precedence order (C3 linearization); I believe that those are a bit too much. conflicts can be resolved by redefining the method in the child class, so no need for automation here. As long as super calls allow to pick and chose the parent method you want, so you can explicitely combine them as you want, in the order you want, or simply ignore one if you want. So i wouldn't define 'full MI' with the assumption that "the inheritance model automatically resolves conflicts;" One could say it even gives more power to the programmers, as it would inform them in those 'ambiguous' cases. > - the MRO is entirely dependendent on the shape of the inheritance > graph, and not on incidental properties like the name of classes; This is something we want, yeah, but it is not a given in python... ``` class Top: pass class Left(Top): pass print(Left.__mro__) # Left, Top class Right(Top): pass class Bottom(Left, Right): pass print(Bottom.__mro__) # Bottom, Left, Right, Top ``` As you can see, Left MRO when subclassed by Bottom is different from Left MRO when taken alone. (even if it can be found in a subsequence) This means that a refactoring consisting of extracting the class Top from Left and Right is technically a breaking change, from a lib author point of view. We might wanna get rid of that. > - the inheritance model is consistent, monotonic and preserves local > precedence order (C3 linearization); I'm unclear on what you mean by consistent. Local precedence order should probably be conserved, i'm not arguing against that. But monotonicity, i don't think so. with the exemple above, Bottom MRO could be "Bottom, Left, Top, Right, Top", this is not monotonic, but not inconsistent either. Probably even more consistent? essentially, it could be for any class : "class, [MRO from class first parent], [MRO from the second parent], ..." That would be even more consistent than today's MRO which by subclassing allows MRO injection And there would not be any inconsistent inheritence tree, except maybe if a class happens to be in its own inheritance tree. You also argued somewhere, sorry i can't find it back to quote it, that it's a good thing that an error is raised in case we're doing an inconsistent class hierarchy, but i'd argue it is a problem, since there's no way out this error. Even when you know what you're doing. Those class inheritence trees are barred from the language now, no matter what. Greg Ewings writes: > There's nothing incoherent or inconsistent about the way C++ > and Eiffel do MI. The main difference is that they require you > to explicitly resolve conflicts between inherited methods -- > which is arguably more Pythonic than Python, since they refuse > the temptation to guess. That's actually the very reason why i named this thread "mro and super don't feel so pythonic" Can't agree more with you here. ___ 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/PIP2VRDF7XNYWLQE5YLSLX4JWFGKB6ZM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
On 16/04/22 10:46 pm, Steven D'Aprano wrote: On Sat, Apr 16, 2022 at 05:56:13PM +1200, Greg Ewing wrote: There's nothing incoherent or inconsistent about the way C++ and Eiffel do MI. Good thing I never said that they were incoherent or inconsistent. You seemed to be implying that, though. You claim that the C3 algorithm is the only way to get MI that is coherent and consistent. If that's true, then since C++ and Eiffel don't use C3, they must not be coherent and consistent. There is no *guessing* in the C3 linearization algorithm. "Guessing" in the context of that Zen line means making an arbitrary choice that may or may not be what the programmer wants. It doesn't mean choosing at random. -- Greg ___ 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/H7DCU2P2465PWU2NNTLVQURWG6VCIOGT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
On 16/04/22 11:13 pm, Steven D'Aprano wrote: So we might say that all inheritance is delegation, but not all delegation is inheritance. We might even go further and say that any delegation to a superclass (not just the direct parent) is a form of manual inheritance. To my way of thinking, delegation is when you call a method of a *different* object. With a super call (either explicit or implicit) you're calling a different method of the *same* object. Think about the ordinary meaning of the word "delegation". When you delegate a task, you give it to someone *else* to do. If instead you just find a different way of doing it yourself, you wouldn't call that delegation. So I would say that none of the things we're talking about here are examples of delegation. -- Greg ___ 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/HE2HDBITU7PLOJCCQ6UKFKZSZDZM44Z6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditions for a coherent MI relationship [was Re: Re: mro and super don't feel so pythonic]
On 16/04/22 10:26 pm, Steven D'Aprano wrote: C++ and Eiffel are even stricter (more restrictive) than Python. They don't just exclude class hierarchies which are inconsistent, they exclude class hierarchies with perfectly good linearizations because they have a method conflict. No, they don't *exclude* such hierarchies, they just require you to resolve the conflicts explicitly. no matter how many times I say that other choices for MI are legitimate and maybe even better than Python's choice So by saying that something is "not full MI", you didn't mean to imply that it is somehow inferior and less desirable? Because that's what you sounded like you were saying, and why everyone is pushing back so hard on it. The requirement for automatic conflict resolution is kinda necessary for it to be inheritance You seem to have a very different idea of what "inheritance" means from everyone else here. -- Greg ___ 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/CWZLJUDADDF6YGIBCNJA3XDGGTV2522G/ Code of Conduct: http://python.org/psf/codeofconduct/
