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
_______________________________________________
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
