New submission from Arusekk <arek_...@o2.pl>:

If this is a duplicate, please excuse me.

In particular, the most noticeable inaccuracy happens when the postfix if-else 
expression is involved. Maybe there are more of them.
The problem is quite self-explaining. The module named 'dis' will be helpful to 
reproduce the issue.

>>> import dis
>>> code = """(
... [
...     call1(),
...     call2()
... ]
... + call3()
... * call4()
... )"""
>>> dis.dis(code)
  3           0 LOAD_NAME                0 (call1)
              3 CALL_FUNCTION            0 (0 positional, 0 keyword pair)

  4           6 LOAD_NAME                1 (call2)
              9 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             12 BUILD_LIST               2

  6          15 LOAD_NAME                2 (call3)
             18 CALL_FUNCTION            0 (0 positional, 0 keyword pair)

  7          21 LOAD_NAME                3 (call4)
             24 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             27 BINARY_MULTIPLY
             28 BINARY_ADD
             29 RETURN_VALUE
>>> dis.dis(code.replace("+", "if").replace("*", "else"))
  6           0 LOAD_NAME                0 (call3)
              3 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
              6 POP_JUMP_IF_FALSE       25
              9 LOAD_NAME                1 (call1)
             12 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             15 LOAD_NAME                2 (call2)
             18 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             21 BUILD_LIST               2
             24 RETURN_VALUE

  7     >>   25 LOAD_NAME                3 (call4)
             28 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             31 RETURN_VALUE

I used this code to show the difference between if-else and some arithmetics.

AFAICT the feature is possible to implement, as lnotab can contain negative 
line differences.

I don't know whether it is just a bug or a fully intended feature, but it would 
be quite an enhancement to have better line number tracking, useful for 
debugging.

If this is implemented, it may be worth further backporting.

Possible reasons in the upstream Python/compile.c (using < instead of !=):

https://github.com/python/cpython/blob/077059e0f086cf8c8b7fb9d1f053e38ddc743f59/Python/compile.c#L4092

https://github.com/python/cpython/blob/077059e0f086cf8c8b7fb9d1f053e38ddc743f59/Python/compile.c#L4438

----------
components: Interpreter Core
messages: 323371
nosy: Arusekk
priority: normal
severity: normal
status: open
title: Compiler could output more accurate line numbers
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue34372>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to