Home Original page

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

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