[Python-Dev] Decorator order implemented backwards?

[Brett C.]

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