On Wed, 13 Apr 2022 at 21:24, malmiteria <martin.mi...@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 _______________________________________________ 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/ZG2I5T5I53APVPBJIKWK7FGCEVGHXZUT/ Code of Conduct: http://python.org/psf/codeofconduct/
