Making a decorator a staticmethod

[Zac Burns]

To Bruno's first e-mail: Everything you said was correct but largely
off topic. I did already understand these things as well.
To Bruno's second email
quote:
"""
Nope. He's relying on (part of) the interface(s) implemented by the
first argument. The class object itself has nothing to do with is
(well... it does, but only as far as it contribute to the
implementation of the interface expected by the decorator).
"""

Yes - this is exactly what I was trying to communicate. In addition -
perhaps what I should have made clear all along is that the interface
I'm relying on isn't as much of an interface as it is an
implementation. The attributes that I will be accessing are 'local'
(starting with underscores, let's not get into a discussion about this
- I know they aren't really local) and are subject to change as the
implementation of the class changes.

The class provides a 'service' for the inherited classes with
differing behaviors for different method via the decorators it
provides. The details of which I can't get into because it's
proprietary.

If this use case is objectionable to you then fine, I've implemented
my own staticdecorator. (which simply inherits from staticmethod and
implements call). But to those who the use case makes sense for it may
be worth thinking about implementing the call method in the main
distribution.

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games



On Thu, Jan 8, 2009 at 12:21 PM, Bruno Desthuilliers
<bdesth.quelquechose at free.quelquepart.fr> wrote:
> Jonathan Gardner a écrit :
>>
>> On Jan 8, 11:18 am, "Zac Burns" <zac... at gmail.com> wrote:
>>>
>>> In my use case (not the example below) the decorator returns a
>>> function of the form def f(self, *args, **kwargs) which makes use of
>>> attributes on the instance self. So, it only makes sense to use the
>>> staticmethod in the class and in the baseclass. Making this decorator
>>> a module level function doesn't make sense here.
>>>
>>
>> I don't think you should be using staticmethod in this case since you
>> are relying on information in the class itself.
>
> Nope. He's relying on (part of) the interface(s) implemented by the first
> argument. The class object itself has nothing to do with is (well... it
> does, but only as far as it contribute to the implementation of the
> interface expected by the decorator).
>
>
>> (Aside: I really can't think of any reason to use staticmethods in
>> Python other than to organize functions into namespaces, and even
>> then, that's what modules are for, right?)
>
> I sometimes found staticmethods to be useful, in that they provided
> polymorphic dispatch without having to care about the containing module (or
> whether the object thru which the staticmethod_or_function is accessed is a
> module, class or instance).
>
>
>> I think you need to show a better example of what it is you are trying
>> to do.
>
> +1 on this. So far, the only concrete use case for staticmethod as a
> decorator I can think of is the one exposed above for staticmethods in
> general.
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>