-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make static methods created by @staticmethod callable #87848
Comments
Currently, static methods created by the @staticmethod decorator are not callable as regular function. Example: @staticmethod
def func():
print("my func")
class MyClass:
method = func
func() # A: regular function
MyClass.method() # B: class method
MyClass().method() # C: instance method The func() call raises TypeError('staticmethod' object is not callable) exception. I propose to make staticmethod objects callable to get a similar behavior than built-in functions: func = len
class MyClass:
method = func
func("abc") # A: regular function
MyClass.method("abc") # B: class method
MyClass().method("abc") # C: instance method The 3 variants (A, B, C) to call the built-in len() function work just as expected. If static method objects become callable, the 3 variants (A, B, C) will just work. It would avoid the hack like class DocDescriptor:
"""Helper for builtins.open.__doc__
"""
def __get__(self, obj, typ=None):
return (
"open(file, mode='r', buffering=-1, encoding=None, "
"errors=None, newline=None, closefd=True)\n\n" +
open.__doc__)
class OpenWrapper:
"""Wrapper for builtins.open
Trick so that open won't become a bound method when stored
as a class variable (as dbm.dumb does).
See initstdio() in [Python/pylifecycle.c](https://github.com/python/cpython/blob/main/Python/pylifecycle.c).
"""
__doc__ = DocDescriptor()
def __new__(cls, *args, **kwargs):
return open(*args, **kwargs) Currently, it's not possible possible to use directly _pyio.open as a method: class MyClass:
method = _pyio.open whereas "method = io.open" just works because io.open() is a built-in function. See also bpo-43680 "Remove undocumented io.OpenWrapper and _pyio.OpenWrapper" and my thread on python-dev: "Weird io.OpenWrapper hack to use a function as method" |
Seems like a duplicate of bpo-20309. |
My usecase is to avoid any behavior difference between io.open and _pyio.open functions: PEP-399 "Pure Python/C Accelerator Module Compatibility Requirements". Currently, this is a very subtle difference when it's used to define a method. I dislike the current _pyio.OpenWrapper "hack". I would prefer that _pyio.open would be directly usable to define a method. I propose to use @staticmethod, but I am open to other ideas. It could be a new decorator: @staticmethod_or_function. Is it worth it to introduce a new @staticmethod_or_function decorator just to leave @staticmethod unchanged? Note: The PEP-570 "Python Positional-Only Parameters" (implemented in Python 3.8) removed another subtle difference between functions implemented in C and functions implemented in Python. Now functions implemented in Python can only have positional only parameters. |
I don't understand what the problem is. _pyio.open is a function not a static method. >>> import _pyio
>>> _pyio.open
<function open at 0x7f184cf33a10> |
The problem is that _pyio.open doesn't behave exactly as io.open when it's used to define a method: #from io import open
from _pyio import open
class MyClass:
my_open = open
MyClass().my_open("document.txt", "w") This code currently fails with a TypeError, whereas it works with io.open. The problem is that I failed to find a way to create a function in Python which behaves exactly as built-in functions like len() or io.open(). |
Isn't the problem that Python functions are (non-overriding) descriptors, but builtin-functions are not descriptors? How about adding wrappers to make Python functions behave like builtin functions and vice versa? |
My plan for the _pyio module is: (1) Make static methods callable That would only fix the very specific case of _pyio.open(). But open() use case seems to be common enough to became the example in the @staticmethod documentation! Example added in bpo-31567 "Inconsistent documentation around decorators" by: commit 03b9537
|
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 |
If make staticmethod a calllable and always wrap open, we need to change also its repr and add the __doc__ attribute (and perhaps other attributes to make it more interchangeable with the original function). Alternate option: make staticmethod(func) returning func if it is not a descriptor. |
Serhiy Storchaka:
You right and I like this idea! I created PR 25268 to inherit the function attributes (name, __doc__, etc.) in @staticmethod and @classmethod wrappers. |
Currently pydoc on X.sm gives: sm(x, y)
A static method I concur with Mark Shannon. The root problem is that Python functions and built-in functions have different behavior when assigned as class attribute. The former became an instance method, but the latter is not. If wrap builtin open with statickmethod, the repr of open will be something like "staticmethod(<function open at 0x7f03031681b0>)" instead of just "<function open at 0x7f03031681b0>". It is confusing. It will produce a lot of questions why open (and only open) is so special. |
Serhiy:
Do you see a way to make C functions and Python functions behave the same? |
New changeset 507a574 by Victor Stinner in branch 'master': |
Implement __get__ for C functions. Of course it is breaking change so we should first emit a warning. It will force all users to use staticmethod explicitly if they set a C function as a class attribute. We can also start emitting warnings for all callable non-descriptor class attributes. |
Well... such change would impact way more code and sounds to require a painful migration plan. Also, it doesn't prevent to make static methods callable, no? |
Ok, static methods are now callable in Python 3.10. Moreover, @staticmethod and @classmethod copy attributes from the callable object, same as functools.wraps(). Thanks to this change, I was able to propose to PR 25354 "bpo-43680: _pyio.open() becomes a static method". Serhiy: if you want to "Implement __get__ for C functions", I suggest you opening a new issue for that. To be honest, I'm a little bit scared by the migration path, I expect that it will require to fix *many* projects. |
This is a significant change to the language. There may well be a very good reason why static methods have not been made callable before that you have overlooked. Changing static methods to be callable will break backwards compatibility for any code that tests I'm not saying that making staticmethods callable is a bad idea, just that it needs proper discussion. https://bugs.python.org/issue20309 was closed as "won't fix". What has changed? |
Mark Shannon:
Can you please elaborate on why this is an issue? In the pydoc case, it sounds like an enhancement: |
Are you asking why breaking backwards compatibility is an issue? pydoc could be changed to produce the proposed output, it doesn't need this change. We don't know what this change will break, but we do know that it is a potentially breaking change. I don't think you should be making changes like this unilaterally. |
Strictly speaking, adding any method is "potential" breaking change because hasattr(obj, "new_method") become from False to True. And since Python is dynamic language, any change is "potential" breaking change. But we don't treat such change as breaking change. Practical beats purity. In case of staticmethod, I think creating a new thread in python-dev is ideal because it is language core feature. I will post a thread. |
For the record, it's this thread (April 14th, 2021): https://mail.python.org/archives/list/python-dev@python.org/thread/MGQMXSMQIPI5ZKS2T5YHNM47PPWSSRD5/ |
staticmethods are not directly callable in python < 3.10: python/cpython#87848 Signed-off-by: Adam Cmiel <acmiel@redhat.com>
staticmethods are not directly callable in python < 3.10: python/cpython#87848 Signed-off-by: Adam Cmiel <acmiel@redhat.com>
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: