Joao S. O. Bueno writes: > You are still repeating this: > "more in line with the expectation of the majority, " > Though, as already asked, there is zero (nothing) to support that.
I'm also still repeating: People most common experience with super informs their understanding and expectations of super's behavior. This experience will inform them that super proxies "the" (in quotes because it's unclear what it targets, not because it means there's only one, in term of what it teaches users about its behavior) parent. That is not enough to understand its behavior in MI. Also, they would see super always go upward the inheritance trees, so having it going sideway *is* not in line with the expectation of the majority. This is not a "court of law" type of proof, but it's hard to refute that there is a mismacth between expectation informed by experience in simple case and behavior in MI cases. Since simple cases are by far the most common, they do inform the expectation of the majority, i don't know why you think there's nothing to support that. It's also quite "common knowledge" that super is one of the most confusing features of python. I guess that's another argument that supports this same idea. This one has more evidence attached to it, as mentionned by Steven D'Aprano : stackoverflow posts, or even the simple fact that raymond hettinger had to dedicate a talk to this feature. So since it's more evidence based, i guess it's a stronger argument. I get that you've been mostly silent here, but you or anyone else here never answered to this critic of super, except maybe with a "no" type of answer maybe. Very constructive. > I don't think things have improved, but you sure are consuming everyone's > time I wonder why things aren't moving on when no one addresses my answers... > I replied in private as that user's needs could > be fulfilled with a custom metaclass, offering personal help with that (and > did not get a reply). If you are talking about a different mail from your fist answer in this thread, it never reached me, i'm sorry (i checked my spams, but it's not there either). > So, I'd suggest to you, if not for others, at least for myself, that you'd > get some > backup on what this "majority" you claim could be. Could you set, I don't > know, > some online form? With questions like: > > "on the following scenario, what do you [think|prefer] 'super' [does|could > do]?" > > Then we can check. No need for "majority" - get at least some 10 > respondents, with 2 or 3 of those > thinking the same as you, and then maybe it would make sense insisting > on this path, as there could be something in there. Sure, before i start on this path, is anyone else here requesting that too? If there's any question you feel would add value / information to the discussion, let me know. Since the point we're not agreeing on is that people expectations are (or not) in line with super's actual behavior, i think it matter that the questions are open enough. A question that gives a lot of possible answers might hide the fact that someone would have never come up with those answer themselves, which is what their "real life experience" would have been. A question like this one: Chris Angelico writes: > In the given scenario, which of these lines of code would you expect > to have this behaviour? > * super().method() > * ParentClass.method() > * method() > * ::method() > * ^method() > * super[1].method() could come, but only after more open questions, so as not to taint the open questions answers. Eventually, we could also ask people if they have ever seen any of that list of possible answers, or used it themselves. I would add the super(Class).method() syntax in the mix, after all that's my proposal. welcome back chris btw. Another open question is the threshold at which we would all agree there's a problem to be fixed i guess? Joao S. O. Bueno proposes 2-3 over 10, so i guess 25% I'd argue that even a lower number, given the size of the python population, is still a problem. But 25% is fine by me. We could also ask them plainly what they think super should do, in some given scenarios, with multiple possible answers. That's a way to measure what behavior they expect the most, out of multiple possible behavior. Not 'which is the most common expectation' but more 'what expectation out of those specifically is the most common' type of question. Joao S. O. Bueno writes: > Otherwise, just admit these are some features you thought of yourself I did. > not even you seem > to be quite sure of which should be the specs or deterministic outcome (if > any) mathematically deterministic, or "humanly" deterministic? (meaning, majority of people would get the proper expectation, / least surprise, on top of it's behavior being mathematically deterministic). After all, randomisation is deterministic, but we still consider it random. > Get your ideas out into some > packages I've linked it so many times now : https://github.com/malmiteria/super-alternative-to-super/blob/master/parent.py __as_parent__ showcases the feature that could be the ones of super, obviously i named it differently to avoid problems. You might notice it's based on super, as i don't wanna change super's behavior when not needed. I also made it a class bound method, since after all, it only really makes sense in a class, but it could quite as simply be made an unbound method. the method resolution is in the ExplicitMethodResolution class. Note that i do not rely on MRO, for method / attribute resolution, nor do i order parents between themselves. Have fun experimenting with it, feel free to fork / clone it. I've added a bunch of tests to showcase it's behavior. Have a read at those too, they're covering a lot of scenarios. _______________________________________________ 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/BBQ4DBXQZFTSZ5GTRJCRXV7IPL63FWLA/ Code of Conduct: http://python.org/psf/codeofconduct/
