[Python-Dev] Callable, non-descriptor class attributes. (original) (raw)

Steven D'Aprano steve at pearwood.info
Sun Mar 13 02:27:46 CET 2011

Thomas Wouters wrote:

I would much rather loudly warn people to fix their code, instead of forcing other implementations (and, more importantly to me personally, future CPython changes :) to deal with the distinction forever. But if we declare a wrapper to be the right way to deal with this, let's at least do it right, not half-assed again. And if we do add the nondescriptor wrapper for that, I wonder if there are still cases where staticmethods should be callable; it seems to me it would have no real benefit, and it would lure people into a false sense of security when mistakenly using staticmethod as the wrapper (which is, after all, a lot more visible.)

The primary benefit to my mind is two avoid breaking the Principle of Least Astonishment (PLA). Given:

class C(object): @staticmethod def spam(): pass

spam looks like a callable. It is a callable when referenced via C.spam or C().spam. But inside the class block, it isn't callable. That comes as an unpleasant surprise to anyone who, like me, has tried to use a staticmethod as a helper function during class construction:

class C(object): @staticmethod def spam(): pass result = spam()

That something that looks like a function fails to be callable violates PLA. There are work-arounds, but none of them are pretty or obvious:

 # the underlying function doesn't seem to be available directly
 result = spam.__get__(object())

or something like this:

class C(object): def spam(): pass result = spam() spam = staticmethod(spam)

Making staticmethod callable would, in my opinion, be the obvious way to do it.

-- Steven

More information about the Python-Dev mailing list