Class Methods Vs Any Other Callable

Diez B. Roggisch deets at nospam.web.de
Wed May 14 11:56:11 EDT 2008


> When I learned about static methods, I learned they're a way to
> tightly couple some functionality with a class without tying the
> functionality to any of the instances. I see them as nothing more than
> a design decision. To me they make some sense.

Which you can say exactly about classmethods - because there is *no*
instance.
 
> Other than a methods signature (classmethod(cls, l) and a
> staticmethod(l)) a class method does anything that a static method
> does and gets the CLS reference for FREE?

Yes.

> Is this why a static method 
> is considered to be overkill? In other words, either one can be called
> from either the class or the instance and both work pretty much the
> same *but* only the class method includes the class for reference and
> the static method does not?

Yes.
 
> The only real difference I see between an instance and either a class
> or static method is the whole bound/unbound thing. Otherwise, even an
> instance can do what the others do *just* the instance method can only
> make those calls through an instance and not the class.

Which is a pretty heavy distinction. 
 
> Instance methods make the most sense. A static method makes sense too
> *but* I can see how a class method not only does what a static method
> does but how a class method *also* gets the cls reference for free.

I don't understand the last part - but I certainly agree on the "instance
methods make the most sense". But *if* you want a hierarchy
of "sensefulness",

method > classmethod > staticmethod

is the ordering to apply I'd say. Again: classmethods get *more* context
than staticmethods *without* needing an instance. More is better :)

Diez



More information about the Python-list mailing list