[Python-Dev] Decorator order implemented backwards? (original) (raw)

Brett C. bac at OCF.Berkeley.EDU
Sun Aug 15 22:05:28 CEST 2004

Mark Russell wrote:

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).

=) I kept doing cvs update, just waiting for someone to fix this right in the middle of me doing all of this.

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 testevalorder() in testdecorators.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 am leaving this up to Guido (seems to have become the default PEP 318 champion) to make the decision on the order. Personally I like my order more since I would expect evaluation of arguments to be in the order listed, just the application order to be reversed.

Either way I won't be able to deal with this patch if it is accepted; with the python-dev Summary coverage period ending today I still have 728 emails to summarize on top of any sent in today so I will be swamped with that for the rest of the week. I am sure someone else can step up and applying it if Guido okays the application order.

-Brett

More information about the Python-Dev mailing list