@staticmethod vs module-level function

Question

This is not about @staticmethod and @classmethod! I know how staticmethod works. What I want to know is the proper use cases for @staticmethod vs. a module-level function.

I've googled this question, and it seems there's some general agreement that module-level functions are preferred over static methods because it's more pythonic. Static methods have the advantage of being bound to its class, which may make sense if only that class uses it. However, in Python functionality is usually organized by module not class, so usually making it a module function makes sense too.

Static methods can also be overridden by subclasses, which is an advantage or disadvantage depending on how you look at it. Although, static methods are usually "functionally pure" so overriding it may not be smart, but it may be convenient sometimes (though this may be one of those "convenient, but NEVER DO IT" kind of things only experience can teach you).

Are there any general rule-of-thumbs for using either staticmethod or module-level functions? What concrete advantages or disadvantages do they have (e.g. future extension, external extension, readability)? If possible, also provide a case example.

Answer 1

Technically a static method and a module function behave pretty much identically - In both cases they work like standard functions, the difference being the namespace where they are placed. So the decision is more one of maintainability/readability.

Generally I would use a static method if some or all of these criteria are met:

• There is already an existing class with normal methods
• The function relates to objects of the class generally, but not one specific instance
• You want to be able to call the method as if it's a non-static method, possibly because you may want to make the method non-static in the future without breaking client code

Answer 2

Here's an argument for @staticmethod from a readability standpoint.

class Foo:
   def a(self):
      ...

   def b(self:
      ...

   @staticmethod
   def c():
      ...

You can now call methods on Foo without the caller having any idea of the implementation differences.

from foomodule import Foo
Foo().a().b().c()

Whereas a function the implementation requires a different call

from foomodule import Foo, c
foo.a().b()
c()

Granted, you could also do Foo.c(), but this breaks from the convention so I prefer to avoid it because then if c() ever did become an instance method, the code would need changed everywhere it's accessed.

The other major argument, which I don't have the experience to speak to, is how difficult is it to mock a static method in python for testing. If it's challenging, as it is in languages like Java, then perhaps function is the way to go.

Answer 3

A program is a simulation of a piece of reality. This way, it depends on how you perceive the reality.

A function represents some activity. The more the activity is general, the bigger is the tendency to simulate the activity with a function. Methods are bound to classes. The more the activity is specific to the class, the more it tends to be simulated by a method.

Think about the trigonometric functions. Say, the sin() is so well known that you know it fits with angles. You know that it wants a float number as input and returns the float. Anyway, there can be an angle datatype represented by a class and the .sin() without argument could be a normal method that works with the angle object, and .sin(x) with a single argument could be a static method of the class. I could bet that more people think that it is better to make sin() a plain function. They are more used to.

Another viewpoint: A module resembles a class instance. It has its own member variables and member functions. In some sense, it implements a singleton pattern. Whenever you import it from another module of the application, you get the access to exactly the same variables and functions.

Answer 4

I have a function that will take some part of an object's deep data hierarchy as an argument. It would be cumbersome to instead pass in the several arguments needed to get to that part of the data hierarchy. So have no reason to reference self or cls. But the functionality will only be used on parts of objects of a particular class. So it seems a class method to me.

Further, I prefer to import the class name ('from module import class' rather than 'import module'). Including the function as a static method gives me access to the method while writing it as a module-level function would require a different import.