On Wed, 27 Apr 2022 at 08:06, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > > On 27/04/22 1:04 am, Joao S. O. Bueno wrote: > > MonkeyPatching in Python is not illegal in this sense. > > I'm not suggesting it is. You're seizing on the wrong part > of the analogy. The point is that what you call something > doesn't change its nature. >
I agree. So why is it monkeypatching sometimes, and not other times? Why are you distinguishing? To be clear, this is what I'm responding to: On Tue, 26 Apr 2022 at 10:05, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > To me, monkeypatching means modifying the definition of something > after the fact in a way that it wasn't designed for. > > Here, the modification is fully intended, so it's not monkeypatching. You're saying that it's somehow different when the original dev intends for it, and that that makes it "not monkeypatching". I dispute that, and I consider that the feature would be helpful whether the original dev meant for it or not. Consider what Python would be like if every class had to declare whether it was allowed to be subclassed or not. Would subclassing therefore become legitimate if the original author intended for it, and be called "method stealing" if it were not? Would that materially improve the language? I have frequently subclassed something without the "consent" of the original class's author, because it is a useful feature. Python is a "consenting adults" language. If you do something the original author didn't intend, you might find yourself running into backward compatibility issues, but you shouldn't have the language block you unnecessarily. ChrisA _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2BGUHWOUNJTVETANBVJPCVPQZ43IVA57/ Code of Conduct: http://python.org/psf/codeofconduct/
