[issue27127] Never have GET_ITER not followed by FOR_ITER

Changes by Demur Rumed : -- resolution: -> rejected status: open -> closed ___ Python tracker ___

[issue27127] Never have GET_ITER not followed by FOR_ITER

Serhiy Storchaka added the comment: As Dino noted in msg266453, this leaves the iterable on the stack while the loop is running. I think opcode reworking shouldn't change behavior. You should call GET_ITER or FOR_BEGIN before calling generator code. --

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: I should've kept gitfit & forbegin more separated as issues. Attached is gitfit2, which only folds the GET_ITER into the comprehension if it isn't a generator so to pass test_genexps -- Added file: http://bugs.python.org/file43300/gitfit2.patch

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Didn't see Raymond's response before posting, forbegin3 at least exists as a completion of the experiment to a passes-tests state. The tracing hacks to support an instruction corresponding to two separate lines support rejecting this idea --

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Attaching forbegin3.patch. It reintroduces GET_ITER for the sole purpose of eagerly throwing. I decided to reuse GET_ITER over something like TEST_ITER as this way we can have GET_ITER flow into FOR_BEGIN & rely on the fast path of iter(iter(x))

[issue27127] Never have GET_ITER not followed by FOR_ITER

Raymond Hettinger added the comment: I don't think this should go forward. The current FOR_ITER and JUMP_ABSOLUTE combination is very efficient and shouldn't be changed lightly. It is the inside of the loop that matters -- the GET_ITER step is outside of the loop and isn't expensive. Also,

[issue27127] Never have GET_ITER not followed by FOR_ITER

Serhiy Storchaka added the comment: What if generate following code? GET_ITER JUMP_FORWARD L2 L1: # ... L2: FOR_ITER L1 This saves one jump instruction per iteration. Next, we can merge GET_ITER+JUMP_FORWARD in one FOR_BEGIN instruction for regular loops. Generators will

[issue27127] Never have GET_ITER not followed by FOR_ITER

Changes by Demur Rumed : Added file: http://bugs.python.org/file43271/forbegin2.patch ___ Python tracker ___

[issue27127] Never have GET_ITER not followed by FOR_ITER

Changes by Demur Rumed : Removed file: http://bugs.python.org/file43270/forbegin2.patch ___ Python tracker ___

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Attached is a patch which fixes test_sys_settrace & test_pdb & test_trace. Still failing is test_genexps. I'm unsure the best way to fix this one: 1. Allow generator expressions to defer type errors about non iterables until the initial call to next 2. Create a

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: I've gotten most tests to past by having FOR_ITER be traced as if the instruction index is that of the corresponding FOR_BEGIN. test_sys_settrace still fails on test_15_loops because an empty loop body doesn't have the 'pass' line traced (ie when FOR_ITER starts

[issue27127] Never have GET_ITER not followed by FOR_ITER

Serhiy Storchaka added the comment: It looks to me this idea is dead. -- ___ Python tracker ___ ___

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Two issues: One: `a = (i for i in 6)` does not throw until calling next(a). This applies to the first patch. If it's unacceptable to defer the throw then this whole issue should be closed unless there's interest in having a GET_ITER, FOR_ITER, FOR_BEGIN,

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Summer heat is getting to me. Please ignore this issue until I've uploaded a fixed patch -- ___ Python tracker ___

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Microbenchmark of continue regression: timeit("for a in range(256):\n\tif a:continue",number=10) Without patch: ~3.57 With patch: ~3.64 -- ___ Python tracker

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Pretty small perf increase: timeit("for a in range(256):pass", number=10) Without patch: ~2.1 With patch: ~1.84 pybench is 1-2% faster. Would prefer others' results. Especially a benchmark where it doesn't wrap payloads in for loops --

[issue27127] Never have GET_ITER not followed by FOR_ITER

Serhiy Storchaka added the comment: Ah, sorry. You are right. Do you have any microbenchmarks that shows the benefit? -- stage: -> patch review ___ Python tracker

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Currently it'll work since in an except it'll generate a CONTINUE_LOOP that'll jump to the end of the loop & either jump back to the start or to the end Your example is incorrect. If the continue's JUMP_ABS were a FOR_ITER then if we were on the last iteration

[issue27127] Never have GET_ITER not followed by FOR_ITER

Serhiy Storchaka added the comment: Interesting. How it works with continue? for x in a: if x: continue f() In this case we can use new FOR_ITER instead of JUMP_ABSOLUTE. I would rename FOR_ITER to something more appropriate (maybe containing NEXT or CONTINUE). How it

[issue27127] Never have GET_ITER not followed by FOR_ITER

Demur Rumed added the comment: Attached is the larger potential change of replacing GET_ITER/FOR_ITER with FOR_BEGIN/FOR_ITER. I took awhile to getting this put together due to missing that CONTINUE_LOOP was jumping to the top of the loop, skipping past FOR_ITER -- Added file:

[issue27127] Never have GET_ITER not followed by FOR_ITER

Dino Viehland added the comment: I like how this makes the loop opcodes more regular - it should make things like Pyjion (http://www.github.com/Microsoft/Pyjion) which translate bytecode into native code. We already have some code (currently commented out) checking that GET_ITER is followed

[issue27127] Never have GET_ITER not followed by FOR_ITER

New submission from Demur Rumed: This is a small change to comprehensions pass in their iterable rather than calling GET_ITER before CALL_FUNCTION. This makes it so that the compiler never generates GET_ITER without following it with FOR_ITER, nor does it generate FOR_ITER without preceding