On Sun, 2004-08-15 at 08:22, Brett C. wrote:
Mark Russell wrote:
[SNIP - stuff about the order]
I'll do a patch to fix the order and the corresponding tests.
I hope I am not stepping on Mark's toes but I went ahead and fixed it to be bottom-up like the PEP.
Now that's what I call timing :-) I finished the patch to fix this yesterday and decided to leave it until today to upload (I've been swamped this week, hence the delay getting time to do this). I've uploaded it now (as patch #1009560) because I think it is a more correct fix (as well as also fixing the Lib/compiler package). It turns out that the order of evaluation of issue is more subtle than it first appears. Here's the comment from the start of the new test_eval_order() in test_decorators.py: # Evaluating a decorated function involves four steps for each # decorator-maker (the function that returns a decorator): # # 1: Evaluate the decorator-maker name # 2: Evaluate the decorator-maker arguments (if any) # 3: Call the decorator-maker to make a decorator # 4: Call the decorator # # When there are multiple decorators, these steps should be # performed in the above order for each decorator, but we should # iterate through the decorators in the reverse of the order # they appear in the source. Your patch results in the evaluation order: evalname1 evalargs1 makedec1 evalname2 evalargs2 makedec2 evalname3 evalargs3 makedec3 calldec3 calldec2 calldec1 Mine (#1009560) gives: evalname3 evalargs3 makedec3 calldec3 evalname2 evalargs2 makedec2 calldec2 evalname1 evalargs1 makedec1 calldec1 I would defend this as the correct order because it is the same as the order you get with the current method (func = staticmethod(func)).
I did not make any changes to to force decorators on to a single line, though. Mark can still have that one. =)
Thanks :-) My patch implements that change as well (plus doc and test updates to match). Mark