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

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.

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.

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.