Performance impact of using decorators

vinjvinj vinjvinj at gmail.com
Fri Mar 10 11:42:06 EST 2006


>> solution. I'm not going to tell you that decorators aren't the answer to
>>all programming problems, because you already know that in your heart :-

I was fearing that. The expose decorator is the only one that comes
with cherrypy. The other ones are mine and are of the format:

def decorator(func):
    def wrapper(self, *args, **kwargs)
         some code
    return wrapper

I'll stick with what I'm doing currently and eventually (if the need
arises from a performance perspective) merge the three into one
decorator. I'll also need to eventually add a caching docrator.Do other
people have this problem, especially for developing web applications.
How many decorators, if any, do you use?

@expose -> cherrypy decorator
@startTransactrionAndBuildPage -> starts a db transaction, populates
the user in the session. Does some error handling. Adds header, footer
and error messages to the page.
@partOfTabUi -> besides the top level navigation, I have tab level
(with actions) for navigation on individual pages
@convert -> this converts boolean like 'True' or '0' to python True,
'231' -> int
@cache -> (not implemented, but will ad it).

I would love to hear other people's experience with using decorators
for web application building.




More information about the Python-list mailing list