On Wed, 13 Apr 2022 at 21:24, malmiteria <martin.milon@ensc.fr> wrote:
Chris Angelico writes:
A proposal that breaks existing code, and which introduces a new way to do things, will usually require multiple versions of deprecation time in order to be accepted. Nothing is preventing us from doing that here. I already intend to have the adoption syntax come first, since it doesn't break anything pre existing, it can be added, and a few version later, the breaking change can happen, you've got your deprecation time.
Your proposed syntax "class A(B(C)):" is currently valid syntax. You cannot claim that it "doesn't break anything".
That usually means either a compatibility period, or a means of continuing to use the older syntax. A compatibility period is probably the only way for the entire proposal, but for most parts of it, i'm pretty sure it could be possible to have the older syntax still apply.
Are you actually proposing to have two completely different class keywords? If not, what do you mean by "older syntax"? Be very clear. That said, though: I still think your proposal is solving a problem that is much MUCH better solved by ... not using inheritance. Class inheritance is NOT the same as biological parentage. But if you are going to make a proposal, be sure to acknowledge the breaking changes. ChrisA