[Python-Dev] why different between staticmethod and classmethod on non-callable object? (original) (raw)

Terry Reedy tjreedy at udel.edu
Wed Sep 2 07:53:05 CEST 2009

P.J. Eby wrote:

At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote:

Greg Ewing wrote:

Benjamin Peterson wrote:

It depends on whether you're keeping the "callable" object around or not. Somebody could add a call method later. Good point. Removing the check sounds like the right thing to do, then. Both classmethod & staticmethod are documented as having a function (callable, as I interprete that) as their single argument. Seems reasonable to me. Turning the argument into a function after the fact seems like a really esoteric use case. The main use case for staticmethod is to prevent get from being called on an object retrieved from a class or an instance. It just happens that the most common types of objects you'd want to do that on are functions.

If so, then it is mis-named and mis-documented, and it seems to me that there is a rationale (not necessarily determinative) for the current difference in implementation.

However, if for some reason you intend to make a descriptor available as an attribute (via a class default), then wrapping it with staticmethod is the only easy way to do it.

For example, if you're writing a class whose instances have an attribute that holds a "property" instance, and you want to provide a class-level default, the simplest way to do it is to wrap the default property instance with staticmethod, so that it's not treated as a property of the class/instance. (Property instances are of course not callable.)

So that it is a 'static object' in some sense, but not a static method.

Thanks for the clarification and example.

tjr

More information about the Python-Dev mailing list