On Thu, 21 Apr 2022 at 02:45, malmiteria <martin.mi...@ensc.fr> wrote: > > 4) Lib refactoring are breaking changes > A Lib author refactoring his code by extracting a class as a parent class of > multiple of the class provided is introducing a breaking change. > Because any user's code inheriting from at least 2 of the class impacted by > this refactoring will now exhibit a different behavior. > If O1 and O2 are refactored into N1(GP) and N2(GP) > the MRO as it was before refactoring was essentially N1, GP, N2, GP, as what > was O1 before refactoring is equivalent to N1, GP after refactoring. > After refactoring, the MRO is now N1, N2, GP. Which do behave differently, in > general.
This seems important. The refactoring can cause a problem if both of O1 and O2 have an attribute (or method) say "a", and O1.a goes to GP, and O2.a goes to N2. While O1.a would more naturally be going to N1 (or some class between N1 and GP), the fact is it must! I don't think I have ever been told a refactoring like that shouldn't involve a new instance of overriding. Is this known to most Python programmers? I wish every Python programmer will know it. Best regards, Takuo Matsuoka _______________________________________________ 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/F3VEMOUPZ7JQZ3FPQ25HF7HRG7IDCLGZ/ Code of Conduct: http://python.org/psf/codeofconduct/
