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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com