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

Signify that a SyntaxError comes from an fstring in the error message #85256

Closed
lysnikolaou opened this issue Jun 22, 2020 · 11 comments
Closed
Labels
3.9 only security fixes 3.10 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@lysnikolaou
Copy link
Contributor

BPO 41084
Nosy @gvanrossum, @vstinner, @ericvsmith, @lysnikolaou, @pablogsal, @miss-islington
PRs
  • bpo-41084: Adjust message when an f-string expression causes a SyntaxError #21084
  • [3.9] bpo-41084: Adjust message when an f-string expression causes a SyntaxError (GH-21084) #21188
  • [3.9] bpo-41084: Fix test_fstring failure when using the old parser #21212
  • 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 2020-06-29.13:03:43.826>
    created_at = <Date 2020-06-22.23:53:42.299>
    labels = ['interpreter-core', 'type-feature', '3.9', '3.10']
    title = 'Signify that a SyntaxError comes from an fstring in the error message'
    updated_at = <Date 2020-06-29.13:03:43.825>
    user = 'https://github.com/lysnikolaou'

    bugs.python.org fields:

    activity = <Date 2020-06-29.13:03:43.825>
    actor = 'lys.nikolaou'
    assignee = 'none'
    closed = True
    closed_date = <Date 2020-06-29.13:03:43.826>
    closer = 'lys.nikolaou'
    components = ['Interpreter Core']
    creation = <Date 2020-06-22.23:53:42.299>
    creator = 'lys.nikolaou'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 41084
    keywords = ['patch']
    message_count = 11.0
    messages = ['372134', '372136', '372150', '372422', '372471', '372472', '372477', '372478', '372562', '372570', '372572']
    nosy_count = 6.0
    nosy_names = ['gvanrossum', 'vstinner', 'eric.smith', 'lys.nikolaou', 'pablogsal', 'miss-islington']
    pr_nums = ['21084', '21188', '21212']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue41084'
    versions = ['Python 3.9', 'Python 3.10']

    @lysnikolaou
    Copy link
    Contributor Author

    It's relatively easy to identify if a SyntaxError occurs when parsing an fstring expression or not. The idea is to slightly change the error message to start with "f-string: " when it does (in the same way in which SyntaxError messages are produced by the hand-written fstring parser). I have a working PR that produces the following:

    $ cat a.py
    f'{a $ b}'
    $ ./python.exe a.py
      File "/Users/lysnikolaou/Repositories/cpython/a.py", line 1
        (a $ b)
           ^
    SyntaxError: f-string: invalid syntax

    Thoughts?

    @lysnikolaou lysnikolaou added 3.9 only security fixes 3.10 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels Jun 22, 2020
    @ericvsmith
    Copy link
    Member

    I think it's a good idea.

    My only reservation would be: if the parsing of f-strings is moved into the parser, would it be possible to maintain the error new messages?

    @lysnikolaou
    Copy link
    Contributor Author

    My only reservation would be: if the parsing of f-strings is moved into the parser, would it be possible to maintain the error new messages?

    Probably without a single change.

    @pablogsal
    Copy link
    Member

    New changeset 2e0a920 by Lysandros Nikolaou in branch 'master':
    bpo-41084: Adjust message when an f-string expression causes a SyntaxError (GH-21084)
    2e0a920

    @lysnikolaou
    Copy link
    Contributor Author

    Should we maybe backport this to 3.9 as well?

    @pablogsal
    Copy link
    Member

    I would say yes unless someone sees an obvious impediment

    @ericvsmith
    Copy link
    Member

    AFAIK, we don't guarantee the stability of error messages, so I think backporting is fine. It's all the better that this is just prefixing something to an existing error message.

    @miss-islington
    Copy link
    Contributor

    New changeset cb0dc52 by Miss Islington (bot) in branch '3.9':
    bpo-41084: Adjust message when an f-string expression causes a SyntaxError (GH-21084)
    cb0dc52

    @vstinner
    Copy link
    Member

    The change broke the old parser in Python 3.9, I reopen the issue:

    AMD64 Arch Linux VintageParser 3.9:
    https://buildbot.python.org/all/#/builders/765/builds/129

    FAIL: test_format_specifier_expressions (test.test_fstring.TestCase) (str="f'{4:{/5}}'")
    FAIL: test_invalid_syntax_error_message (test.test_fstring.TestCase)
    FAIL: test_lambda (test.test_fstring.TestCase) (str="f'{lambda x:x}'")
    FAIL: test_parens_in_expressions (test.test_fstring.TestCase) (str="f'{,}'")
    FAIL: test_parens_in_expressions (test.test_fstring.TestCase) (str="f'{,}'")

    @vstinner vstinner reopened this Jun 29, 2020
    @vstinner vstinner reopened this Jun 29, 2020
    @pablogsal
    Copy link
    Member

    New changeset 990efe0 by Lysandros Nikolaou in branch '3.9':
    [3.9] bpo-41084: Fix test_fstring failure when using the old parser (GH-21212)
    990efe0

    @lysnikolaou
    Copy link
    Contributor Author

    Thanks, Victor!

    The fix is merged, so I'm closing this again.

    @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
    Labels
    3.9 only security fixes 3.10 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants