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 _pyio.Wrapper:

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"
https://mail.python.org/archives/list/python-dev@python.org/thread/QZ7SFW3IW3S2C5RMRJZOOUFSHHUINNME/

Seems like a duplicate of bpo-20309.

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>

I don't understand what the problem is. _pyio.open is a function not a static method.

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?
Changing static methods is not going to fix that.

How about adding wrappers to make Python functions behave like builtin functions and vice versa?

Changing static methods is not going to fix that.

My plan for the _pyio module is:

(1) Make static methods callable
(2) Decorate _pyio.open() with @staticmethod

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!
https://docs.python.org/dev/library/functions.html#staticmethod

Example added in bpo-31567 "Inconsistent documentation around decorators" by: commit 03b9537

commit 03b9537dc515d10528f83c920d38910b95755aff
Author: Éric Araujo \<merwok@users.noreply.github.com\>
Date:   Thu Oct 12 12:28:55 2017 -0400

    bpo-31567: more decorator markup fixes in docs (GH-3959) (bpo-3966)

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

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:

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

You right and I like this idea! I created PR 25268 to inherit the function attributes (name, __doc__, etc.) in @staticmethod and @classmethod wrappers.

There is a nice side effect of PR 25268 + PR 25117: pydoc provides better self documentation for the following code:

class X:
    @staticmethod
    def sm(x, y):
        '''A static method'''
        ...

pydoc on X.sm:

sm(x, y)
    A static method

instead of:

<staticmethod object>

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:

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.

Do you see a way to make C functions and Python functions behave the same?

New changeset 507a574 by Victor Stinner in branch 'master':
bpo-43682: @staticmethod inherits attributes (GH-25268)
507a574

Do you see a way to make C functions and Python functions behave the same?

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.

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?

New changeset 553ee27 by Victor Stinner in branch 'master':
bpo-43682: Make staticmethod objects callable (GH-25117)
553ee27

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 should be a PEP, or at the very least a discussion on Python Dev.

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 callable(x) where x is a static method.

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:

Changing static methods to be callable will break backwards compatibility for any code that tests callable(x) where x is a static method.

Can you please elaborate on why this is an issue?

In the pydoc case, it sounds like an enhancement:
https://bugs.python.org/issue43682#msg390525

Are you asking why breaking backwards compatibility is an issue?
Or how it breaks backwards compatibility?

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.
callable(staticmethod(f)) will change from False to True.

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.
We can use beta period to see is this change breaks real world application.

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.

@methane:

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/