STINNER Victor <[email protected]> added the comment:
> Isn't the problem that Python functions are (non-overriding) descriptors, but
> builtin-functions are not descriptors?
> Changing static methods is not going to fix that.
> How about adding wrappers to make Python functions behave like builtin
> functions and vice versa?
I would love consistency, but is that possible without breaking almost all
Python projects?
Honestly, I'm annoying by the having to use staticmethod(), or at least the
fact that built-in functions and functions implemented in Python don't behave
the same. It's hard to remind if a stdlib function requires staticmethod() or
not. Moreover, maybe staticmethod() is not needed today, but it would become
required tomorrow if the built-in function becomes a Python function somehow.
So yeah, I would prefer consistency. But backward compatibility may enter into
the game as usual. PR 25117 tries to minimize the risk of backward
compatibility issues.
For example, if we add __get__() to built-in methods and a bound method is
created on the following example, it means that all code relying on the current
behavior of built-in functions (don't use staticmethod) would break :-(
---
class MyClass:
# built-in function currently converted to a method
# magically without having to use staticmethod()
method = len
---
Would it be possible to remove __get__() from FunctionType to allow using a
Python function as a method? How much code would it break? :-) What would
create the bound method on a method call?
---
def func():
...
class MyClass:
method = func
# magic happens here!
bound_method = MyClass().method
---
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue43682>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
