Decorators: an outsider's perspective

Chas Emerick cemerick at snowtide.com
Sun Aug 15 09:34:30 EDT 2004


On August 14, 2004 9:35:48 AM EDT, Paul Morrow wrote:

>    def blah(a, b):         # this is clearly a static method
>       pass
>
>    def blah(self, a, b):   # this is clearly an instance method
>       pass

Ouch.  Sorry, the arguments going into a function shouldn't have 
**anything** to do with the nature of that function.  Overloading their 
existence, lack thereof, or their names as a way of describing the 
function they are hung off of seems like a horrible way to go.  (Not to 
mention the fact that, at least conceptually, it is also violating that 
action-at-a-distance guideline...)

On Aug 14, 2004, at 11:35 AM, Paul Morrow wrote:

> Yes, sorry, but I'm in a pickle here.  I want (we need) the general 
> idea of decorators --- the realm of problems that decorators try to 
> solve --- to be made smaller.  They should not be used to declare a 
> method's type (static|instance|class).  Decorators may have some valid 
> purpose, but this is not one of them.

I would almost agree with you anywhere else.  However, since GvM has 
explicitly overruled the idea of something like:

def static blah (args):
	pass

we're left to find other routes by which to specify method types.  
Decorators neatly provide a generalized way to modify functions, so 
that's where static|instance|class modifications land.  I agree that 
that's slightly unfortunate at the moment, but it's probably 
necessitated by the history of using the horrible foo=staticmethod(foo) 
idiom.

I say 'at the moment', because I can imagine quite a few decorators 
that definitely touch on the notion of a function's type.  Consider:

@remote([remoteFuncName], [accessRestrictions], ...)
def static blah (args):
	pass

That might make blah available over xmlrpc, for example, though some 
route predefined in whatever xmlrpc library one happens to be using.  
Again, I'm no expert in python, so perhaps there's already similarly 
easy ways to configure such things with the libraries that already 
exist, but I think I got my point out there.

On , Hans Nowak wrote:

> This post wasn't deriding decorators; rather, it explains them, and 
> provides some examples of how to use them.  I do question their 
> usefulness, but I'm not deriding them, nor the "@" syntax.

Sorry if I mischaracterized your intent...I meant no harm.  :-)

- Chas Emerick




More information about the Python-list mailing list