Today I give thanks

…To whoever came up with the decorator module for Python. (“Whoever”? It seems to be some guy named Michele Simionato.)

My page generation library uses a lot of decorators. For instance, if a method is invoked to generate a page, it is decorated with @makepage, and voilà! the proper methods for generating the page as a whole are invoked, and though the method only returns some content to go in the content <div>, it will be a proper XHTML document with menus, etc. A method that generates Javascript? @makejs and it returns it with the proper MIME type. Need to check permissions? @checkPerm('admin') ensures that mere users cannot delete what they should not be able to delete even if they craft their POST requests to target methods they shouldn’t.

The problem is that this interferes with another mechanism my pages use. POST data are used for various parameters: Some special variables are used to determine call type and authentication; some are used for __init__() parameters to set up page objects; others are used as arguments to the methods subsequently invoked. In order to figure out what should go where, the framework relies on inspect.getargspec() to figure out what the parameters to a method may be. Currently it can’t handle methods that take *args and/or **kwargs; if I ever need it I’ll add it. The problem is, when you write general decorators, the signature of the decorated functions will tend to end up in the form (*args, **kwargs)… Now my framwork using getargspec() is unable to figure out what POST variables should be passed in and, consequently, passes in no arguments.

Fortunately, it turns out that someone else had recognised that this was a general problem, and the decorator module is written precisely to solve the problem of decorated functions losing their signatures. The module page describes both problem and solution in greater detail. Go forth, enjoy, and stay Pythonic!