The line number for the frame object changed behaviour in 3.8.

I am seeing this on Fedora rawhide, which ships "3.8.0~b4-1.fc32" package.

That happens when wrapping lines for calling functions.

Before, the line number sys._getframe(1).f_lineno indicate the last line. Now it is the first line.



Reproducer:

>>>
#!/usr/bin/env python

import sys


def func(a, b, c, d):

    frame = sys._getframe(1)

    print('call: %s' % (a))
    print('frame:                %s' % (frame))
    print('frame.f_code.co_name: %s' % (frame.f_code.co_name))
    print('frame.f_lineno:       %s' % (frame.f_lineno))


func('call 1, 1 line', 0, 1, 2)

func('call 2, 2 lines',
     0, 1, 2)

func('call 3, 4 lines',
     0,
     1,
     2)

<<<<


with python2 and python<=3.7, the line numbers are 16, 19, 24, respectively.

With 3.8, it changes to 16, 18, 21.

Right, it is intended change.

Do you have a reference to the discussion about that?

See issue12458 and issue34372.

Related issues: issue34876, issue16806, issue31241.

OK, I see. Thanks for the references.

FWIW, I think such changes in behavior are really bad. The issue should be fixed without changing existing API.

Yes, of course. We could keep f_lineno unchanged, despite the fact that its value can be wrong, and introduce f_lineno_new. Then we should change all code in the stdlib which uses f_lineno to use f_new_lineno, or rather, to keep absolute backward compatibility, add other duplicates: warnings.warn_new(), traceback.print_stack_new(), etc, and encourage all third-party projects to change their code too.

But there are some drawbacks in such approach.

> We could keep f_lineno unchanged, despite the fact that its value can be wrong

It was not completely wrong. It was seemingly good enough for the past 20+ years.


The change in behaviour is one thing. It's also inconvenient that, even when being aware of the change in behaviour, there is no workaround to get the same number across python versions. Something like:

  if hasattr(frame, 'f_lineno_legacy'):
      return frame.f_lineno_legacy
  else
      return frame.f_lineno

Are you aware of such a workaround?


> But there are some drawbacks in such approach.

Definitely. While I don't agree with the decision and priorities for how the final approach was chosen, thank you for explaining them :)

No, I do not know such workaround. At best, you can analyze the code object and get the line number of the next instruction. It may be the line past the last line of the function call, or be equal to it if the function call is the part of complex expression or if you write several statements on the line. Then you need to analyze the sources.

The information about the first line of the multiline expression looks more useful than information about the last line. And it is more consistent with other cases. Maybe in future we will add information about the range of lines for every expression and statement (some steps was already made in this direction). But this is more complex change.