[issue34876] Python3.8 changes how decorators are traced

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: New changeset 95b6acf951fa7f503a3cc5ce7d969d7bcf2f95c9 by Serhiy Storchaka in branch 'master': bpo-34876: Change the lineno of the AST for decorated function and class. (GH-9731) https://github.com/python/cpython/commit/95b6acf951fa7f503a3cc5ce7d969d7bcf2f

[issue34876] Python3.8 changes how decorators are traced

Ned Batchelder added the comment: Thanks, the fix looks good to me. I made a comparison of some decorator tracing to check it out: https://gist.github.com/nedbat/d603a34136299f0c0b8e442fccadeb7d TBH, the first time I tried it, something seemed wrong, but I can't see it now, so ¯\_(ツ)_/¯ :)

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: Ned, please look at PR 9731. Does it fixes the issue to you? Georg, you had added the original code for patching the lineno of decorated function. Are your good to remove this patch and to move updating the first line number at the code generation stage?

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: See 09aaa88328a5083469b2682230c7f3c62942afab. The position of the AST node for decorated function and class was changed to the position of the first decorator. It was made to help inspect.getsource() for functions to include decorator lines in the result.

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: Seems PR 9731 fixes this issue. I'll add tests later. -- ___ Python tracker ___ ___ Python-bugs

[issue34876] Python3.8 changes how decorators are traced

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +9117 stage: -> patch review ___ Python tracker ___ ___ Python-bugs

[issue34876] Python3.8 changes how decorators are traced

Ned Batchelder added the comment: This is the --trace output for some stacked decorators: $ cat -n /tmp/decdec.py 1 def decorator1(f): 2 return f 3 4 def decorator2(f): 5 return f 6 7 def decorator3(f): 8 return f 9 10 @decora

[issue34876] Python3.8 changes how decorators are traced

Terry J. Reedy added the comment: I have never looked at the trace of a decorated object before. The 3.7 behavior treating the inner decorator line as the first line of the decorated function definition looks wrong to me. I actually expected the line pointer to move down to the def line, a

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: First the decorator itself is loaded. Then the function is created, decorators are called and the result is bound to the name. There is similar situation in the case of multiline call. $ cat -n multiline_call.py 1 def f(a, b): 2 return [

[issue34876] Python3.8 changes how decorators are traced

Ned Batchelder added the comment: Yes, I agree that the assignment statement behavior is fine. The stacked decorator behavior is not. I understand that under the hood the two cases are very similar, but the syntax is different. Jumping back to the first decorator makes it look like the de

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: I think this is a correct behavior. $ cat -n multiline_assignment.py 1 x = 1 2 y = 2 3 z = [ 4 x, 5 y, 6 ] $ ./python -m trace --trace multiline_assignment.py In 3.7 the line with the assignment is missed: ---

[issue34876] Python3.8 changes how decorators are traced

Ned Batchelder added the comment: Are we sure this is the behavior we want? Now when I step through your code in the debugger, it will show me line 2, then 3, then 4, then 2 again. I can see the appeal for a multiline assignment statement, but for stacked decorators it just seems wrong. ---

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: On other hand, consider the following example of multiline assignment: $ rlwrap ./python -m dis a = [ x, y, ] In 3.7: 2 0 LOAD_NAME0 (x) 3 2 LOAD_NAME1 (y) 4 BUILD_LIST

[issue34876] Python3.8 changes how decorators are traced

Serhiy Storchaka added the comment: This is because the first line of the function definition was the line of the last decorator in 3.7, and it is the line of the first decorator in 3.8. $ rlwrap ./python -m dis @decorator @decorator @decorator def func(): pass In 3.7: 2 0

[issue34876] Python3.8 changes how decorators are traced

Ammar Askar added the comment: It looks like this is caused by https://github.com/python/cpython/commit/da8d72c953369b872a12c13f136ada77a786714a Adding Serhiy to the nosy list. -- nosy: +ammar2, serhiy.storchaka ___ Python tracker

[issue34876] Python3.8 changes how decorators are traced

New submission from Ned Batchelder : When decorating a function, the sequence of lines reported to the trace function is different in Python3.8 than with previous versions $ cat -n decorator.py 1 def decorator(f): 2 return f 3 4 def f(): 5 @decorator 6