> 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 -- http://mail.python.org/mailman/listinfo/python-list
