On 2018-04-12 14:57, Serhiy Storchaka wrote: > If noddy_name is a Python function, noddy.name() will call > noddy_name(noddy), but if it is a C function, noddy.name() will call > noddy_name(). > > The same is true for classes and custom callables.
FWIW, you could (almost) do this in py2: >>> class Str(str): pass ... >>> Str.print = types.MethodType(print, None, Str) >>> Str("hello").print() hello > If a function is a descriptor, it can be converted into non-descriptor > function by wrapping it with the staticmethod decorator. I suggest to > add the method decorator, which converts an rbitrary callable into a > descriptor. > > class Noddy: > name = method(noddy_name) > > This will help to implement only performance critical method of a class > in C. Does the method decorator need to be written in C for the performance benefit? If you can stand __get__ being Python, it's pretty easy to write and doesn't need to change the language. This does remind me of my favourite silly functional Python trick: as long as foo is implemented in Python, foo.__get__(x)(y,z) is equivalent to foo(x,y,z), which is useful if you find Python's standard partial application syntax too ugly. > Currently you need to implement a base class in C, and inherit > Python class from C class. But this doesn't work when the class should > be inherited from other C class, or when an existing class should be > patched like in total_ordering. > > This will help also to use custom callables as methods. I wonder if it wouldn't make more sense to make the behaviour consistent between Python and C functions... that someclass.blah = a_python_function already does a frequently-wrong thing suggests (to me) that maybe the proper solution would be to bring back unbound method objects. Ed
Description: OpenPGP digital signature
_______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/