Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Parenthesized expression has incorrect line numbers #78553

Closed
Arusekk mannequin opened this issue Aug 10, 2018 · 3 comments
Closed

Parenthesized expression has incorrect line numbers #78553

Arusekk mannequin opened this issue Aug 10, 2018 · 3 comments
Assignees
@serhiy-storchaka
Labels
3.8 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@Arusekk
Copy link
Mannequin

Arusekk mannequin commented Aug 10, 2018

BPO 34372
Nosy @serhiy-storchaka, @ammaraskar, @Arusekk
Superseder
  • bpo-12458: Tracebacks should contain the first line of continuation lines
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2018-09-24.16:39:23.984>
created_at = <Date 2018-08-10.15:02:24.445>
labels = ['interpreter-core', 'type-bug', '3.8']
title = 'Parenthesized expression has incorrect line numbers'
updated_at = <Date 2018-09-24.16:39:23.983>
user = 'https://github.com/Arusekk'

    bugs.python.org fields:

    activity = <Date 2018-09-24.16:39:23.983>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2018-09-24.16:39:23.984>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2018-08-10.15:02:24.445>
creator = 'Arusekk'
dependencies = []
files = []
hgrepos = []
issue_num = 34372
keywords = []
message_count = 3.0
messages = ['323371', '323556', '323577']
nosy_count = 3.0
nosy_names = ['serhiy.storchaka', 'ammar2', 'Arusekk']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '12458'
type = 'behavior'
url = 'https://bugs.python.org/issue34372'
versions = ['Python 3.8']
    @Arusekk
    Copy link
    Mannequin Author

    Arusekk mannequin commented Aug 10, 2018

    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 !=):

    cpython/Python/compile.c

    Line 4092 in 077059e

    if (e->lineno > c->u->u_lineno) {

    cpython/Python/compile.c

    Line 4438 in 077059e

    if (e->lineno > c->u->u_lineno) {

    @Arusekk Arusekk mannequin added 3.7 (EOL) end of life 3.8 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Aug 10, 2018
    @ammaraskar
    Copy link
    Member

    Note that even just adding an extra arithmetic in your first expression breaks the line numbers:

    >>> code = """(                                    
... [                                              
...   call1(),                                     
...   call2()                                      
... ]                                              
... + call3()                                      
... * call4()                                      
... + call5()                                      
... )"""                                           
>>> dis.dis(code)                                  
  8           0 LOAD_NAME                0 (call1) 
              2 CALL_FUNCTION            0         
              4 LOAD_NAME                1 (call2) 
              6 CALL_FUNCTION            0         
              8 BUILD_LIST               2         
             10 LOAD_NAME                2 (call3) 
             12 CALL_FUNCTION            0         
             14 LOAD_NAME                3 (call4) 
             16 CALL_FUNCTION            0         
             18 BINARY_MULTIPLY                    
             20 BINARY_ADD                         
             22 LOAD_NAME                4 (call5) 
             24 CALL_FUNCTION            0         
             26 BINARY_ADD                         
             28 RETURN_VALUE

    The closest existing bug to this would be bpo-12458, specifically with Serhiy's last comment.

    @ammaraskar ammaraskar changed the title Compiler could output more accurate line numbers Parenthesized expression has incorrect line numbers Aug 15, 2018
    @serhiy-storchaka serhiy-storchaka self-assigned this Aug 15, 2018
    @serhiy-storchaka
    Copy link
    Member

    If the proposed solution for bpo-12458 be merged, this issue will be closed as a duplicate. Otherwise I have a simpler solution for this particular case (and few other cases, but not all cases in bpo-12458).

    @serhiy-storchaka serhiy-storchaka removed the 3.7 (EOL) end of life label Sep 24, 2018
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @serhiy-storchaka serhiy-storchaka

    Labels
    3.8 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @ammaraskar @serhiy-storchaka