decorators tutorials

[Josiah Carlson]

james_027 wrote:
> hi bruno,
> 
> That seems to be hard to read at all, or I am just very new to python?

No, it's hard to read.  Note that it's not, technically, necessary to 
use nested functions to get the same results as a particular decorator. 
  For example, earlier you provided...

def check_login(func):
     def _check_login(*args):
         print "I am decorator"
         return func(*args)
     return _check_login

That could be written as...

class check_login:
     def __init__(self, func):
         self.func = func
     def __call__(self, *args):
         print "I am decorator"
         return self.func(*args)

The latter class-based method is a bit clunkier, but I find that it's 
easier to understand and unravel after the fact (you can also add your 
own __repr__ method for useful introspection).


> With that decorator how do I take advantage of it compare when I just
> write a function that could do the same as what the decorator did? I
> could translate the could from above into ...
> 
> def check_login(msg):
>    #...
> def my_func(toto, tata):
>    #...
> 
> #call it like this
> check_login('msg')
> my_func('toto', 'tata')

There are many uses for decorators (I'm sure others have posted about 
them already), and really, the syntax is a convenience meant to reduce 
the number of times you need to type the same string...

@long_decorator
def realy_long_function_name():
     ...

rather than...

def realy_long_function_name():
     ...
realy_long_function_name = long_decorator(realy_long_function_name)


I try to limit my use of decorators whenever possible, both because I 
still have to support Python 2.3 (which doesn't support the syntax), and 
because I find that they obfuscate what the code is doing more often 
than not.  I will admit that they are useful as a metaprogramming 
technique.  Just be careful.

  - Josiah