> 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.
`class A(B(C))` is already a valid Python syntax (for example you could use `class A(namedtuple(...))`), your change to add a specific meaning to this syntax would break existing code. Le mar. 12 avr. 2022 à 23:22, Eric V. Smith <e...@trueblade.com> a écrit : > 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 > > _______________________________________________ > 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/KWXDZBGZBX3LLCP3FQ33T27YUXDKXXL5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo
_______________________________________________ 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/XWL6V6ACH4M2OZTDBVZ5TY777IFB5I75/ Code of Conduct: http://python.org/psf/codeofconduct/
