Decorators are very wonderful things, but if used as this article shows, they destroy the method signature of the function; fibonacci() goes from being a function that takes one argument to a function that appears as if it will take as many arguments as you give it. (That's the *args syntax; it collects all the arguments into a list.)
Usually this is not a problem, but some people want to see the correct method signature when they look up the documentation (often auto-generated) for a function. And there are some programs that inspect the method signature and expect it to be correct.
I agree, but as I tried to make clear in the article, I've only tried to make the code as generalized as possible. For the memoize class for example, you wouldn't care. For the safe class, you'd definitely write in more exceptions to handle more issues your source might have. In this process, you'd be writing the proper method signature in.
You're right though, I should have made that clearer.
Not really familiar with TurboGears, but it's always awesome to see an app leveraging a language's natural power and flexibility.
I concur about decorators being "insanely easy to use"--taking the memoization example I presented in the article; it's far, far simpler to tack on "@memoize" than to incorporate it into the flow of a function and risk losing clarity. I am sure TurboGears (and Django/Pylons) authors love that you can decorate something with @login_required (or equivalent) and have that method exposed to authentication.
Usually this is not a problem, but some people want to see the correct method signature when they look up the documentation (often auto-generated) for a function. And there are some programs that inspect the method signature and expect it to be correct.
http://www.phyast.pitt.edu/~micheles/python/documentation.ht... provides more details on this subject, as well as a library to mitigate this problem. I believe functools.wraps in python2.5 also solves this problem: http://docs.python.org/lib/module-functools.html