[Python-Dev] Decorator order implemented backwards?

[Mark Russell]

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