[Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

Steve Dower steve.dower at python.org
Fri Feb 10 13:11:46 EST 2017


When you apply the "what if everyone did this" rule, it looks like a bad idea (or alternatively, what if two people who weren't expecting anyone else to do this did it).

Monkeypatching is fairly blatantly taking advantage of the object model in a way that is not "supported" and cannot behave well in the context of everyone doing it, whereas inheritance or mixins are safe. Making a dedicated syntax or decorator for patching is saying that we (the language) think you should do it. (The extension_method decorator sends exactly the wrong message about what it's doing.)

Enabling a __class__ variable within the scope of the definition would also solve the motivating example, and is less likely to lead to code where you need to review multiple modules and determine whole-program import order to figure out why your calls do not work.

Top-posted from my Windows Phone

-----Original Message-----
From: "Markus Meskanen" <markusmeskanen at gmail.com>
Sent: ‎2/‎10/‎2017 10:18
To: "Paul Moore" <p.f.moore at gmail.com>
Cc: "Python-Ideas" <python-ideas at python.org>; "Steve Dower" <steve.dower at python.org>
Subject: Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

Well yes, but I think you're a bit too fast on labeling it a mistake to use monkey patching...




On Feb 10, 2017 18:15, "Paul Moore" <p.f.moore at gmail.com> wrote:

On 10 February 2017 at 16:09, Markus Meskanen <markusmeskanen at gmail.com> wrote:
> But if people are gonna do it anyways with the tools provided (monkey
> patching), why not provide them with better tools?


Because encouraging and making it easier for people to make mistakes
is the wrong thing to do, surely?

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170210/631025d0/attachment.html>


More information about the Python-ideas mailing list