Message389917
> 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
--- |
|
Date |
User |
Action |
Args |
2021-03-31 16:42:18 | vstinner | set | recipients:
+ vstinner, rhettinger, mark.dickinson, Mark.Shannon |
2021-03-31 16:42:18 | vstinner | set | messageid: <1617208938.91.0.98799520952.issue43682@roundup.psfhosted.org> |
2021-03-31 16:42:18 | vstinner | link | issue43682 messages |
2021-03-31 16:42:18 | vstinner | create | |
|