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