This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Demur Rumed
Recipients Demur Rumed, dino.viehland, serhiy.storchaka
Date 2016-05-30.01:13:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1464570811.85.0.520237440076.issue27127@psf.upfronthosting.co.za>
In-reply-to
Content
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, FOR_NEXT set of opcodes between comprehensions & for loops. That seems excessive

Two: tracing is getting a bit confused by FOR_ITER being at the end of the loop body. The clearest example is that in test_pdb's test_pdb_until_command_generator it needs 3 steps instead of 2 to trace `print(i)` after the 'until 4' because whereas currently it traces the `for i in test_gen()` before calling into the iterator, it now calls into the iterator first & traces `for i in test_gen()` only after returning. Additionally it doesn't trace `for i in test_gen()` at the end of iteration, instead tracing the last line

It seems fragile to try fix this up by having the FOR_ITER tail receive a negative lnotab line offset to place it on the same line as the loop heading. My own research of the code base has been trying to determine if I can manually emit a trace in the FOR_ITER opcode, but I'd rather not muck with the frame to carry out this façade
History
Date User Action Args
2016-05-30 01:13:31Demur Rumedsetrecipients: + Demur Rumed, dino.viehland, serhiy.storchaka
2016-05-30 01:13:31Demur Rumedsetmessageid: <1464570811.85.0.520237440076.issue27127@psf.upfronthosting.co.za>
2016-05-30 01:13:31Demur Rumedlinkissue27127 messages
2016-05-30 01:13:30Demur Rumedcreate