-
They have a baked in reference to the class. When you inherit from the class, you get a different reference.
The most common purpose is to provide an alternate initializer -- f.ex. dict.fromkeys.
-
classmethod() is good for creating a method where the implicit first argument will be either the class it is defined on *or* a subclass.
staticmethod() is good for using a class as a namespace for essentially just a function. You access the "function" via the class or an instance of the class, but they're not passed as arguments.
I think classmethod() is more useful. For staticmethod, I would probably just use a function in the module of the class. At least that's what I have done so far.
-
How about if you're actually needing to do a gen_build_ini() on a class passed to you by a factory? I could think of situations where just defining another build_ini() factory would be counterproductive, especially if you start serialising objects and flinging them around networks...
-
You write:
After reading the first three comments: I
understand that class methods have an implicit reference to the class they're referring to, and I also understand how and when they are used. My point is, I'm still wondering what they can do what a function can't. I mean, the class method MyClass.foo() could easily be coded as a function foo(MyClass) (with the exact same code, it seems).
Consider this question: Why do class instances have methods? What can they do that a function can't? I mean, the instance method myObj.foo(a,b) could easily be coded as a function foo(self, a, b) (with the exact same code, it seems).
Meditate on that, and you will become enlightened. <wink>
-
"""Consider this question: Why do class instances have methods? What can they do that a function can't? I mean, the instance method myObj.foo(a,b) could easily be coded as a function foo(self, a, b) (with the exact same code, it seems)."""
Actually, I did think about that... and found the answer disturbing. :-) From one point of view, Python classes/objects are really not much more than syntactic sugar around something that can be simulated with structs and functions.
OK, it's not that bad. OOP has some important benefits, like inheritance and polymorphism. The benefit of regular methods seems considerable... the benefit of class methods much less so, IMHO. But maybe that's because they are used less often. Or maybe it's because before they existed (pre-2.2), one would write a function to achieve the same effect, so maybe functions seem more "traditional" here.
Of course, it also ties into the metaclass concept... a class is an instance too, so from that POV, it's only natural that it has methods as well. From the pre-2.2 POV, it makes less sense.