On 4/12/2022 12:57 PM, malmiteria wrote:
So the amount of actual breakings left shouldn't be enough to justify denying this feature IMO. Again, we'll have a clearer view on that once we get experimental data. What's to look for is usage of super in MI cases, since each super call in MI today should be replaced by one super call per parent, in my proposal. If this turns out to be an issue, we can try to imagine solution for it. Maybe a solution such as : super calls implicitely run a super call to each parent when there's multiple parent, and super isn't given arguments. This i think would behave strictly as today's super + MRO, except for cases where one class appears multiple time in an inheritance tree. The last breaking change would be that scenario, class appearing multiple time in an inheritance tree. And we're getting on even rarer occasions here, but again, we can think of solutions here.
I have code in a non-public repository that your proposed change will break. I'm sure I'm not the only one. It is not realistic to implement a change like this that will break code and then say "there's a workaround that you'll need to implement". Especially for library code that needs to run across multiple python versions.
As much as i understand we don't want breaking change, i don't think it is *that* strong an argument, in this case. And, on its own, breaking changes aren't a strict veto, there's been some, and there's gonna be more.
As a long-time core developer, I can assure you that this is one of those cases where a breaking change will not be allowed. I'm trying to save you some time here, but if you're committed to continuing this, then you can't say you weren't warned when it's ultimately rejected. My suggestion is to rework your proposal to not break any existing code. It's a constraint we've all had to live with at one time or another, as much as we don't like it. Eric