Decorator

[bruno at modulix]

Martin Blume wrote:
> "bruno at modulix" schrieb 
> 
>>[snip]
>>
>>The use case for @decorator is for wrapping functions
>>or method *in the module/class itself*. 
> 
> That was the question. What's the use of doing it 
> like that in the module *itself* 
Readability.

Since the decoration (in the module) is somehow part of the function
definition, it's more obvious to have it expressed with a modifier-like
syntax at the top of the def statement than expressed as a function call
and rebinding after the end of def block. When reading the code, with
the @decorator syntax, the use of the decorator is pretty evident.

Once again, this is nothing more than syntactic sugar - but syntactic
sugar counts. FWIW, function decorators seems to be *much* more used
since the introduction of the @decorator syntax, when you could do the
same thing since the introduction of nested scopes and closures in
Python (dont remember the version, but this is not really new).

> (I mean, you change
> directly the original function)?

If you mean that the code added by the decorator could be injected
directly in the function, that's not always true (ie: classmethod and
staticmethod for example), and it just plain sucks anyway - you don't
write a decorator for a single function, you write it to separate
orthogonal concerns, like tracing, handling auth, partial application of
function, etc...

>>It's not for module client code (but this of
>>course doesn't prevent client code to dynamically 
>>add other wrappers...)
>>
> 
> How do the clients it? 

Like it did since there are nested scopes and closures in Python. Higher
order functions are not really something new, you know - Lisp had them
way back in 1958 !-)

> The "oldfashioned"
> deco(doSillyWalk)
> way?

from monty.python import Cleese
Cleese.doSillyWalk = deco(Cleese.doSillyWalk)

HTH
-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"