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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4