Making a decorator a staticmethod

[Bruno Desthuilliers]

Zac Burns a écrit :
> To Bruno's first e-mail: Everything you said was correct but largely
> off topic.

for a definition of "off topic" equals to "didn't fit your expectations".

> I did already understand these things as well.

Sorry - but it was not necessarily obvious from your post, and it's near 
to impossible to guess someone's background on a single post basis. So 
please don't hold it against me. Anyway, you're not the only people 
reading this group, and some readers might not have the same knowledge.

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

Ok.

> The class provides a 'service' for the inherited classes with
> differing behaviors for different method via the decorators it
> provides. 

Not sure it's quite clear to me, but I think I get the whole picture.

> The details of which I can't get into because it's
> proprietary.

No problem - the above precisions are enough IMHO.

> If this use case is objectionable to you then fine,  I've implemented
> my own staticdecorator. 

What I still find questionable is the "necessity" to make your 
decorators part of the base class. OO is about objects - not classes - 
and Python's functions _are_ objects (just like modules, classes and 
everything else FWIW), so even if your decorators are bound to a 
specific implementation, well, what's the problem ? (BTW, please read 
until the end of the post before replying). Just document the fact that 
they only accept instances of your base class, and that's enough - well, 
IMHO at least !-).

Anyway, given Python's highly dynamic nature, being an instance of a 
given class _at a given moment in time_ doesn't garantee you have this 
or this _implementation attribute - at best, it makes it highly 
plausible, but that's all you can expect, really.

> (which simply inherits from staticmethod and
> implements call).

If it makes you feel better - no judgement call on this, I personnaly 
care a lot about feeling good with my own code, and perfectly understand 
we don't all have the same feeling about what looks right or wrong -, 
then go for it. FWIW, I might even agree with your choice if I saw the 
real code and knew the whole context. My point was just that it was not 
*technically* necessary to make the decorators part of the base class !-)

> But to those who the use case makes sense for it may
> be worth thinking about implementing the call method in the main
> distribution.

Python is a free, opensource software, so feel free to send the patch - 
who knows, it might even be accepted if don't break anything. But 
prepare to make your point, the BDFL tends to be very conservative 
(which is a very GoodThing(tm) IMHO).