[issue34705] Python 3.8 changes how returns through finally clauses are traced

Mark Shannon added the comment: In master, the sequence of events is: 1 call 2 line 3 line returning 4 line 6 line finally 6 return which is the same as 3.7. I now believe this is the correct trace, as the language spec states: When a return, break or continue statement is executed in the

[issue34705] Python 3.8 changes how returns through finally clauses are traced

Mark Shannon added the comment: When I get a chance I'll see what happens with https://github.com/python/cpython/pull/6641 -- ___ Python tracker ___

[issue34705] Python 3.8 changes how returns through finally clauses are traced

Mark Shannon added the comment: The new behaviour looks the more correct to me. Arguably the sequence should not include the second "4 line", but is otherwise correct. -- ___ Python tracker

[issue34705] Python 3.8 changes how returns through finally clauses are traced

Serhiy Storchaka added the comment: I think that this can be fixed. But this is not easy. -- ___ Python tracker ___ ___

[issue34705] Python 3.8 changes how returns through finally clauses are traced

Ned Batchelder added the comment: I can't tell if you think this is something that should be fixed, or not? (Also, I'm not getting email notifications from bpo, sorry for the delay). -- ___ Python tracker

[issue34705] Python 3.8 changes how returns through finally clauses are traced

Serhiy Storchaka added the comment: Humm, the optimization is not related here. Even if it is not involved (replace 17 with []), the line 4 is reported twice, because RETURN_VALUE is executed after CALL_FINALLY. 4 10 BUILD_LIST 0 12 POP_BLOCK

[issue34705] Python 3.8 changes how returns through finally clauses are traced

Serhiy Storchaka added the comment: This is a side effect of specific optimization. If the return value is constant, it is pushed on the stack after executing the finally code (see LOAD_CONST at offset 14 below). But other opcodes at this line (POP_BLOCK and CALL_FINALLY) are executed after

[issue34705] Python 3.8 changes how returns through finally clauses are traced

Ned Batchelder added the comment: This affects coverage.py, as reported in this bug: https://github.com/nedbat/coveragepy/issues/707 -- ___ Python tracker ___

[issue34705] Python 3.8 changes how returns through finally clauses are traced

New submission from Ned Batchelder : When a return statement also executes a finally clause, the sequence of lines reported to the trace function is different in 3.8 than it has been before 3.8: $ cat finally_trace.py def return_from_finally(): try: print("returning")