[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Mark Shannon added the comment: I think this is now fixed. Ned, feel free to reopen if it still isn't fixed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker __

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Mark Shannon added the comment: New changeset 4c53e63cc966f98e141a09bc435b9f9c713b152d by Mark Shannon (Pablo Galindo) in branch 'master': bpo-39166: Fix trace of last iteration of async for loops (#17800) https://github.com/python/cpython/commit/4c53e63cc966f98e141a09bc435b9f9c713b152d ---

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +17237 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17800 ___ Python tracker __

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Pablo Galindo Salgado added the comment: > I'm a little confused: there's a program in this issue to demonstrate the > problem. Can I do something to make it easier for you to use? Sorry for the confusion, I was asking because at the time of asking I didn't have access to a computer to chec

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Ned Batchelder added the comment: Pablo, thanks, but that PR does not fix this problem. I'm a little confused: there's a program in this issue to demonstrate the problem. Can I do something to make it easier for you to use? -- ___ Python tracker

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Pablo Galindo Salgado added the comment: Can you check if this is fixed with the changes in: https://github.com/python/cpython/pull/17769 -- nosy: +pablogsal ___ Python tracker _

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Karthikeyan Singaravelan added the comment: Bisecting points me to fee552669f . I tried compiling latest master with the bytecode changes and the behavior is same as reported. ➜ cpython git:(5dcc06f6e0) ./python ../backups/bpo39166.py > fee552669f_before.txt ➜ cpython git:(5dcc06f6e0) ✗ git

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Change by Karthikeyan Singaravelan : -- nosy: +asvetlov, yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Ned Batchelder added the comment: I see that you are right, the bytecode is the same in 3.8 and 3.9. Nevertheless, the trace has definitely changed. Using the same program from the top of the issue, here are the ends of the traces for a number of Python versions. The extra trace of line 32

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

Mark Shannon added the comment: Ned, can you confirm that the trace has changed from 3.8 to 3.9? The bytecode for `doit_async` is identical for 3.8 and 3.9. -- ___ Python tracker ___

[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

New submission from Ned Batchelder : 3.9.0a2 changed how the final iteration of "async for" is traced. The body of the loop is traced when the body is not executed. Standard "for" loops don't show the same effect. In the output below, notice that 3.9.0a2 and 3.9.0a2+ both show one last exe