On Tue, Apr 12, 2022 at 1:59 PM malmiteria <martin.milon@ensc.fr> wrote:
Ronald Oussoren writes:

> To be blunt: That’s not going to happen because this is big backward compatibility break. Either that, or this adds a
> second way to define classes.  Both are good reasons to keep the status quo.

the breaking is limited MI with name collision, so likely rare enough, and i've already mentionned that i'm perfectly willing to implement my proposal and run it against whatever selection of python repos, to check for real life exemple of breakings, so we can measure how bad it would actually be.

Sorry. 
I thought we were past this point and you had understood and agreed that any change in this respect would not change
the current behavior of MRO and super, requiring either a different call than super, and/or a different metaclass for 
all the hierarchy, to start with.

TL;DR:
***Changing the current behavior of super itself or the MRO formula is just not going to happen.***
 And it is not me saying this.

If you won't spare replying on the list, you can spare yourself from checking "whether this would break things". It would. But
even if it does not break a particular project, that is not negotiable.

And I am not saying that these changes,even as "add-ons" to the language are being considered either - IMHO you failed
so far in presenting any evidence of your point or more people that would  ask for the features you are proposing.

The playful example you brought here with the Gobelin hierarchy, for example, could be addressed with a multitude
of approaches, including custom-metaclases and even `__init_subclass__` methods, that would collect the 
methods with "name collision" and allow one to select a strategy when calling them. 

So, a custom base class or custom metaclass could attend your needs - and that does not need to live
in the language core.

 
The most common case of breaking would be the django style mixins, which i propose a dedicated feature for, adoption.
Essentially a way to declare more than your parent, but their parents too, recursively.
would look like that:
```
class A(B(C)): ...
```
the adoption syntax is non breaking, as it's simply an addition to the language, and has values on its own.
I'll make a dedicated post, but i'm a bit out of time for that now, especially since i'm getting the survey ready.
I'll add some question to get infos that could help debate this feature too, so i guess i'll wait for the survey result.

Once adoption is ... adopted, and start getting used, the more it goes on, the less breaking change will occur.

And, on top of that, the actual change needed to switch from today's solution to adoption is extremly simple.
replace
```
class A(B,C): ...
```
with
```
class A(B(C)): ...
```
That's it.

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.

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.
Overall, they are an upgrade cost we really wanna make as less expensive as possible, but an worthwhile upgrade overcomes the upgrade costs. And, if it improves something, the longer we wait, the more the current behavior can deal its damage, it should be considered in the balance too.
Breaking changes are an momentary cost, while not upgrading might have a smaller, but constant cost.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/LP22REU3YWWLRDOTKAZMTCC5EMHYP53A/
Code of Conduct: http://python.org/psf/codeofconduct/