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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4