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()

> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to