On 31 July 2018 at 01:35, Jonathan Fine wrote:

Hi Jamesie

Thank you for your question. You asked why not

...

c = MyClass o = c()

def c.foo(cls): ... def o.bar(self): ...

I've the same same query, but never had the courage to ask. So that you for asking. And also giving me a chance to share my thoughts.

It's essentially due to the fact that while we deliberately allow runtime monkeypatching (as it's sometimes the best available answer), we also strongly encourage the idea of treating it as a last resort option (outside specific use cases like testing). So if you want to define methods on a class, the strongly preferred place to define them is inside the class definition, where they're easy for future maintainers of that class to find. If you need to replace them for some reason, it will preferably be within a temporary bounded scope, using a tool like unittest.mock.patch, rather than as a permanent change that affects every other use of the class within the process. Cheers, Nick. P.S. While it's *not* explicitly part of Python's design rationale, http://connascence.io/locality.html and the rest of that site provide some good info on the kinds of problems that "action at a distance" effects, like monkeypatching class definitions, can cause in a code base. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

I think C# calls methods that are added to a class "extension methods". You can make a decorator that will do that for you:

def extend(cls):     """     DECORATOR TO ADD METHODS TO CLASSES     :param cls: THE CLASS TO ADD THE METHOD TO     :return:     """     def extender(func):         setattr(cls, get_function_name(func), func)         return func     return extender

and use it

C = MyClass @extend(C) def foo(self, schesome_param):     some_code()

On 2018-07-30 14:12, Chris Barker via Python-ideas wrote:

On Mon, Jul 30, 2018 at 9:10 AM, Nick Coghlan mailto:ncoghlan@gmail.com> wrote:

If you need to replace them for some reason, it will preferably be within a temporary bounded scope, using a tool like unittest.mock.patch, rather than as a permanent change that affects every other use of the class within the process.

 yup -- but you can still do a raw monkey-patch anyway. You asked for:

> Thank you for your question. You asked why not >> c = MyClass >> o = c() >> >> def c.foo(cls): ...

do you mean this? you want a classmethod? or is this what you mean? -- which you can do:

C = MyClass

def foo(self, some_param):     some_code()

C.foo = foo

(note that I used a capital C -- capitalized names are traditional for classes -- see PEP 8)

In that case, any existing, and new instances of the C class will now have the foo method.

Also -- that line: C = MyClass -- binds the name "C" to the very same class object as MyClass -- so you will have just monkey=patched MyClass -- I"m guessing you didn't want that. If not, and you wanted C t be a copy of MyClass that you could then change/add/remove methods from, then you want subclassing -- that is exactly what it is for.

Then there is this:  

>> def o.bar(self): ...

which is monkey patching an instance object, which you can also do, but you don't get a bound method -- i.e. it doesn't get self passed in automatically.

-CHB

 

> I've the same same query, but never had the courage to ask. So that > you for asking. And also giving me a chance to share my thoughts.

It's essentially due to the fact that while we deliberately allow runtime monkeypatching (as it's sometimes the best available answer), we also strongly encourage the idea of treating it as a last resort option (outside specific use cases like testing).

So if you want to define methods on a class, the strongly preferred place to define them is inside the class definition, where they're easy for future maintainers of that class to find.

Cheers, Nick.

P.S. While it's *not* explicitly part of Python's design rationale, http://connascence.io/locality.html http://connascence.io/locality.html and the rest of that site provide some good info on the kinds of problems that "action at a distance" effects, like monkeypatching class definitions, can cause in a code base.

-- Nick Coghlan   |   ncoghlan@gmail.com mailto:ncoghlan@gmail.com   |   Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org mailto:Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/

--

Christopher Barker, Ph.D. Oceanographer

Emergency Response Division NOAA/NOS/OR&R            (206) 526-6959   voice 7600 Sand Point Way NE   (206) 526-6329   fax Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov mailto:Chris.Barker@noaa.gov

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Sorry if my message offended anyone (noted that the "Toxic Forum" post came not long after mine). What I meant is that I cannot defend such an idea before extensively using it. I just don't know how to do it this way. Have a great day

On Tue, Jul 31, 2018 at 10:10:32AM +1200, Greg Ewing wrote:

Jamesie Pic wrote:

...

def o.bar(self): ...

You could get almost the same effect with

from functools import partial

def bar(self, other_args): ...

o.bar = partial(bar, o)

Why are you using functools.partial instead of types.MethodType? I'm wondering if there is some advantage to partial that I don't recognise. I'm not sure if there's a functional difference between the two approaches, but it makes o.bar a different kind of callable and that will probably make a difference to somebody.

But IMO this is nowhere near being a common enough thing to do to justify having special syntax for it.

This sort of thing isn't common because there's no neat, easy, obvious, built-in way to do it. If we allowed people to extend classes using the syntax def classobj.methodname(...): ... def instance.methodname(...): ... people would use the technique more. For good or ill. I don't question the utility of this technique, but I suspect we prefer to *slightly* discourage it by *not* providing a Batteries Included solution for this. If you want to do this, we won't stop you, but neither will we encourage it by supporting it in syntax or providing a standard decorator for it. -- Steve