On Sun, 2004-08-15 at 18:11, David Eppstein wrote:
It would probably be bad style to have any order dependencies in the evalname evalargs makedec parts, but Brett's order makes more sense to me. That is, I like the actual application of decorators to be in nested order, but it makes more sense to me for the lines constructing the decorators to be evaluated in the order they appear in the code.
On second thoughts I think you are right. I was concerned about the difficulty of explaining the two different evaluation orders, but that is outweighed by the non-intuitiveness of having decorator expressions evaluated in the opposite of source code order. I've updated the patch. Here's my current attempt at describing the semantics in the reference manual: A function definition may be wrapped by one or more decorator expressions. Decorator expressions are evaluated when the function is defined, in the scope that contains the function definition. The result must be a callable, which is invoked with the function object as the only argument. The returned value is bound to the function name instead of the function object. Multiple decorators are applied in nested fashion. For example, the following code: @f1(arg) @f2 def func(): pass is equivalent to: def func(): pass func = f1(arg)(f2(func)) Mark