bruno at modulix
onurb at xiludom.gro
Fri May 12 20:11:15 CEST 2006
Martin Blume wrote:
> "bruno at modulix" schrieb
>>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*
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
>>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"
from monty.python import Cleese
Cleese.doSillyWalk = deco(Cleese.doSillyWalk)
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"
More information about the Python-list