[Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity! (original) (raw)

Chris Angelico rosuav at gmail.com
Thu Apr 26 14🔞43 EDT 2018

On Fri, Apr 27, 2018 at 4:07 AM, Larry Hastings <larry at hastings.org> wrote:

* I assume that--if we don't already have one--we'll add a new DUPANDSTOREFAST opcode for binding expressions. On the other hand, "STOREFAST n" followed by "LOADFAST n" is a common enough bytecode idiom that the peephole optimizer could notice it and pretty easily swap it for DUPANDSTOREFAST.

In the reference implementation, it's just DUP_TOP followed by STORE_FAST (well, technically by "whatever the assignment compiles to", as it could be affected by global/nonlocal, closures, etc). Is there much advantage to creating a new opcode?

OTOH, I noticed a lot of STORE_FAST followed by LOAD_FAST in list comprehensions. For instance, [x+1 for x in items] translates to:

1 0 BUILD_LIST 0 2 LOAD_FAST 0 (.0) >> 4 FOR_ITER 12 (to 18) 6 STORE_FAST 1 (x) 8 LOAD_FAST 1 (x) 10 LOAD_CONST 0 (1) 12 BINARY_ADD 14 LIST_APPEND 2 16 JUMP_ABSOLUTE 4 >> 18 RETURN_VALUE

In theory, STORE_FAST followed by LOAD_FAST could be transformed into DUP_TOP followed by STORE_FAST, and then if there is any variable that is stored fast and never loaded, it could be optimized out. That'd leave this with just a DUP_TOP and no variable named 'x'. No idea whether it'd be worth the effort though.

ChrisA

More information about the Python-Dev mailing list