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
signature.asc
Description: OpenPGP digital signature
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
