Hi there,<br><br>It's always bothered me that decorators require a lot of "cruft" to work. Consider an example, from <a href="http://www.python.org/dev/peps/pep-0318/">PEP-318</a> (Decorators for Functions and Methods):<br>

<br><div style="margin-left: 40px;"><font style="font-family: courier new,monospace;" size="2">def returns(rtype):</font><br><font style="font-family: courier new,monospace;" size="2">    def check_returns(f):</font><br>
<font style="font-family: courier new,monospace;" size="2">        def new_f(*args, **kwds):</font><br>
<font style="font-family: courier new,monospace;" size="2">            result = f(*args, **kwds)</font><br><font style="font-family: courier new,monospace;" size="2">            assert isinstance(result, rtype), \</font><br>

<font style="font-family: courier new,monospace;" size="2">                   "return value %r does not match %s" % (result,rtype)</font><br><font style="font-family: courier new,monospace;" size="2">            return result</font><br>

<font style="font-family: courier new,monospace;" size="2">        new_f.func_name = f.func_name</font><br><font style="font-family: courier new,monospace;" size="2">        return new_f</font><br><font style="font-family: courier new,monospace;" size="2">    return check_returns</font><br>

<br></div>It seems to me everything but line 5 "assert..." is cruft. In my mind, it makes sense to call that line the "decoration" (part of the decorator). Since it's a decoration that's executed after the decorated function, it makes sense to call it a post-decoration, one that may be more nicely defined as:<br>

<br><div style="margin-left: 40px;"><span style="font-family: courier new,monospace;">@postdecoration</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">def returns(result, rtype):</span><br style="font-family: courier new,monospace;">

<span style="font-family: courier new,monospace;">    </span><font style="font-family: courier new,monospace;" size="2">assert isinstance(result, rtype), </font><font style="font-family: courier new,monospace;" size="2">"return value %r does not match %s" % (result, rtype)<br>

</font></div><font size="2"><br>Then, `returns' can be used as in PEP-318 (but without the cruft). I've defined similar `decoration', and `predecoration' decorators. I use the latter for my Django views to accept POST parameters as arguments:<br>

<br></font><div style="margin-left: 40px;"><font size="2"><span style="font-family: courier new,monospace;">def filter_dict(d, fltr):<br>    return dict( (str(x.lower()), d[x]) for x in d if x.lower() in fltr )<br><br>@predecoration</span></font><br style="font-family: courier new,monospace;">

<font size="2"><span style="font-family: courier new,monospace;">def takesPOST(f, args):</span></font><br style="font-family: courier new,monospace;"><font size="2"><span style="font-family: courier new,monospace;">    if len(args) == 1:</span></font><br style="font-family: courier new,monospace;">

<font size="2"><span style="font-family: courier new,monospace;">        fargs = getargspec(f).args</span></font><br style="font-family: courier new,monospace;"><font size="2"><span style="font-family: courier new,monospace;">        get = args[0].POST</span></font><br style="font-family: courier new,monospace;">

<font size="2"><span style="font-family: courier new,monospace;">        return filter_dict(get, fargs[1:])</span></font><br></div><font size="2"><br></font><font size="2">This way, I can define a view login(reqest, user, password) which can be called simply from another view, without having to construct a special `request' object.<br>

<br>An initial shot at the definitions is here: <a href="http://gist.github.com/146235">http://gist.github.com/146235</a><br><br>The design decisions I'm least confident about is the argument specs. In the `predecoration' example, the argument `args' is a special name that specifies the arguments passed into the decoratee, `kwargs' would be the keyword arcgs passed into the decorateee, dec_args and dec_params being the arguments passed into the <i>decorator</i>. This doesn't seem like an optimal solution. The problem I'm trying to solve is "moving from a decoration which takes no parameters to a decoration which takes parameters". For example, it was trivial to refactor takesPOST to group POST parameters by regex passed into the decorator. Still, I'm open to questions, ideas, opinions, etc.<br>

<br>What do you guys this?<br><br>Cheers,<br>Andrey<br><br></font>