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.

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

more helpful diagnostics for parser module #80621

Closed
tyomitch mannequin opened this issue Mar 26, 2019 · 11 comments
Closed

more helpful diagnostics for parser module #80621

tyomitch mannequin opened this issue Mar 26, 2019 · 11 comments
Labels
3.8 only security fixes extension-modules C modules in the Modules dir type-feature A feature request or enhancement

Comments

@tyomitch
Copy link
Mannequin

tyomitch mannequin commented Mar 26, 2019

BPO 36440
Nosy @freddrake, @brettcannon, @gpshead, @benjaminp, @berkerpeksag, @serhiy-storchaka, @tyomitch, @pablogsal
PRs
  • bpo-36440: include node names in ParserError messages, instead of numeric IDs #12565
  • [3.7] bpo-36440: include node names in ParserError messages, instead of numeric IDs (GH-12565) #12671
    		•

    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 = None
closed_at = <Date 2019-04-03.18:35:34.402>
created_at = <Date 2019-03-26.15:33:28.777>
labels = ['extension-modules', 'type-feature', '3.8']
title = 'more helpful diagnostics for parser module'
updated_at = <Date 2019-04-06.07:47:33.630>
user = 'https://github.com/tyomitch'

    bugs.python.org fields:

    activity = <Date 2019-04-06.07:47:33.630>
actor = 'xcombelle'
assignee = 'none'
closed = True
closed_date = <Date 2019-04-03.18:35:34.402>
closer = 'pablogsal'
components = ['Extension Modules']
creation = <Date 2019-03-26.15:33:28.777>
creator = 'A. Skrobov'
dependencies = []
files = []
hgrepos = []
issue_num = 36440
keywords = ['patch']
message_count = 11.0
messages = ['338897', '338899', '338900', '338901', '338902', '339378', '339412', '339413', '339414', '339416', '339527']
nosy_count = 9.0
nosy_names = ['fdrake', 'brett.cannon', 'gregory.p.smith', 'benjamin.peterson', 'python-dev', 'berker.peksag', 'serhiy.storchaka', 'A. Skrobov', 'pablogsal']
pr_nums = ['12565', '12671']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue36440'
versions = ['Python 3.8']
    @tyomitch
    Copy link
    Mannequin Author

    tyomitch mannequin commented Mar 26, 2019

    Seeing that the implicit resolution at bpo-36256 was to keep the parser module in place, may I suggest that the diagnostics it produces be improved, so that instead of "Expected node type 305, got 11", it would raise "Expected namedexpr_test, got COLON"

    @tyomitch tyomitch mannequin added 3.9 only security fixes extension-modules C modules in the Modules dir type-feature A feature request or enhancement labels Mar 26, 2019
    @pablogsal
    Copy link
    Member

    Thank you very much for creating the issue :)

    Seeing that the implicit resolution at bpo-36256 was to keep the parser module in place

    Nothing was really "decided", just that meanwhile is better not to ship a broken parser module.

    may I suggest that the diagnostics it produces be improved, so that instead of "Expected node type 305, got 11", it would raise "Expected namedexpr_test, got COLON"

    Would you like to produce a PR for this?

    @pablogsal
    Copy link
    Member

    Haha, you were faster creating the PR than me posting the message!

    @tyomitch
    Copy link
    Mannequin Author

    tyomitch mannequin commented Mar 26, 2019

    Nothing was really "decided", just that meanwhile is better not to ship a broken parser module.

    Totally true, but the issue is closed and resolved, meaning that no one will ever look at it again.

    @pablogsal
    Copy link
    Member

    Meaning that no one will ever look at it again.

    I am very interested in a better alternative to the parser module, so I will open soon another issue for that matter. But as the original issue was about a specific bug, I prefer to mark it as resolved :)

    @serhiy-storchaka serhiy-storchaka added 3.8 only security fixes and removed 3.9 only security fixes labels Mar 31, 2019
    @pablogsal
    Copy link
    Member

    New changeset cb0748d by Pablo Galindo (tyomitch) in branch 'master':
    bpo-36440: include node names in ParserError messages, instead of numeric IDs (GH-12565)
    cb0748d

    @pablogsal
    Copy link
    Member

    New changeset 513d142 by Pablo Galindo in branch '3.7':
    [3.7] bpo-36440: include node names in ParserError messages, instead of numeric IDs (GH-12565) (GH-12671)
    513d142

    @pablogsal
    Copy link
    Member

    Thanks A. Skrobov for your contribution! :)

    @serhiy-storchaka
    Copy link
    Member

    Why was this merged in 3.7? This is a new feature, not a bug fix.

    @pablogsal
    Copy link
    Member

    Issue bpo-36256 (a real bug) was backported to 3.7 but also includes a similar improvement regarding node names in error messages. I can revert it from 3.7 if you consider it should not be there.

    @serhiy-storchaka
    Copy link
    Member

    Since the parser module did not work in 3.7, I think this will not harm. But in general new features (including changes in error messages) are added only in the developed version.

    @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
    No one assigned
    Labels
    3.8 only security fixes extension-modules C modules in the Modules dir type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

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