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

[Thomas Wouters]

On Sat, Mar 12, 2011 at 17:08, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:

> Guido van Rossum wrote:
>
>  IIUC Thomas found that this breaks some current use of staticmethod.
>>
>
> I*I*UC, it wasn't making it callable that was the problem,
> it was changing the behaviour so that the staticmethod
> wrapper returns itself instead of the underlying object
> when accessed as a descriptor.
>
> The reason for doing *that* appears to be so that you
> can transplant a staticmethod-wrapped object from one
> class to another without surprises. But is that really
> a common enough thing to do that it warrants special
> attention? Would it be so bad to require applying
> staticmethod() again in such a situation?
>

There's two different things in play: the traditional use of staticmethod()
when you are storing something that isn't in your control as a class
attribute, and wrapping a Python function to have it be treated like a
PyCFunction, where you have no control (and no desire to control) what
happens with the function. Of course, if you do contor both the 'consumer'
and the 'producer' side, you can fix it either way you want.

For the emulate-builtins wrapper to do a proper job (and not leave subtle
differences lying around), the wrapper should not be a descriptor (or it
should return itself from __get__.) I suspect people will also want it to
expose the original function's attributes, like bound method wrappers do. If
we just have staticmethods be callable and tell people to use that, there
will still be cases where PyCFunctions and wrapped Python functions do
different things. But changing staticmethod to do these things would make
code that relies on staticmethod simply encapsulating objects (like, all my
own uses of staticmethod) break in fascinating ways. (I know, I tried.) And
I don't think having staticmethod do something different depending on the
type of object it's passed is worth considering.

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.)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110312/77995433/attachment.html>