RetroSearch Browse

Sun Mar 13 02:27:46 CET 2011 · http://mail.python.org/pipermail/python-dev/2011-March/109194.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2011-March/109194.html below:

[Python-Dev] Callable, non-descriptor class attributes.