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