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

P.J. Eby pje at telecommunity.com
Wed Sep 2 03:27:08 CEST 2009


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.

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.)



More information about the Python-Dev mailing list