At 09:40 AM 8/17/04 -0700, Michael Chermside wrote:

Mark writes:

...

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

Guido writes:

...

Since Mark ended up agreeing with your order, the OK is given by default. :-)

Wait... I'm confused. What was the final decision? I favor

evalname1 evalargs1 makedec1 evalname2 evalargs2 makedec2 evalname3 evalargs3 makedec3 calldec3 calldec2 calldec1

becase of left-to-right-top-to-bottom evaluation. Is this what it actually does? I imagine this:

Hm. Consider this code: func = a(b)(c(d)(e(func))) Per the PEP, it's the equivalent of: @a(b) @c(d) @e def func(...): ... Here's an annotated disassembly:

...

...

dis.dis(lambda: a(b)(c(d)(e(func)))) 0 SET_LINENO 1 3 LOAD_GLOBAL 0 (a) #evalname1 6 LOAD_GLOBAL 1 (b) #evalargs1 9 CALL_FUNCTION 1 #makedec1 12 LOAD_GLOBAL 2 (c) #evalname2 15 LOAD_GLOBAL 3 (d) #evalargs2 18 CALL_FUNCTION 1 #makedec2 21 LOAD_GLOBAL 4 (e) #evalname3 24 LOAD_GLOBAL 5 (func)#defun 27 CALL_FUNCTION 1 #calldec3 30 CALL_FUNCTION 1 #calldec2 33 CALL_FUNCTION 1 #calldec1 36 RETURN_VALUE

Therefore, this is the evaluation order currently prescribed by the PEP.