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

SyntaxError misidentified in 3.10.0b1 when = used instead of : in dict literal #88346

Closed
aroberge mannequin opened this issue May 19, 2021 · 11 comments
Closed

SyntaxError misidentified in 3.10.0b1 when = used instead of : in dict literal #88346

aroberge mannequin opened this issue May 19, 2021 · 11 comments
Labels
3.10 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@aroberge
Copy link
Mannequin

aroberge mannequin commented May 19, 2021

BPO 44180
Nosy @aroberge, @lysnikolaou, @pablogsal, @miss-islington, @shreyanavigyan
PRs
  • bpo-44180: Report generic syntax errors in the furthest position reached in the first parser pass #26253
  • [3.10] bpo-44180: Report generic syntax errors in the furthest position reached in the first parser pass (GH-26253) #26281
  • bpo-44180: Fix edge cases in invalid assigment rules in the parser #26283
  • [3.10] bpo-44180: Fix edge cases in invalid assigment rules in the parser (GH-26283) #26292
  • 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 = None
    created_at = <Date 2021-05-19.18:38:05.183>
    labels = ['interpreter-core', '3.10']
    title = 'SyntaxError misidentified in 3.10.0b1 when = used instead of : in dict literal'
    updated_at = <Date 2021-05-21.18:20:51.072>
    user = 'https://github.com/aroberge'

    bugs.python.org fields:

    activity = <Date 2021-05-21.18:20:51.072>
    actor = 'miss-islington'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Parser']
    creation = <Date 2021-05-19.18:38:05.183>
    creator = 'aroberge'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 44180
    keywords = ['patch']
    message_count = 10.0
    messages = ['393964', '393965', '393966', '393967', '393968', '393969', '393970', '393971', '394119', '394139']
    nosy_count = 5.0
    nosy_names = ['aroberge', 'lys.nikolaou', 'pablogsal', 'miss-islington', 'shreyanavigyan']
    pr_nums = ['26253', '26281', '26283', '26292']
    priority = 'normal'
    resolution = None
    stage = 'patch review'
    status = 'open'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue44180'
    versions = ['Python 3.10']

    @aroberge
    Copy link
    Mannequin Author

    aroberge mannequin commented May 19, 2021

    When an equal sign is used instead of a colon in creating a dict literal, depending on the context, either the "bad token" is misidentified OR the would-be helpful error message is incorrect in this particular case.

    1. Example of bad token.
      Previously, the = sign was identified correctly:
    >>> ages = {'Alice'=22, 'Bob'=23}
      File "<stdin>", line 1
        ages = {'Alice'=22, 'Bob'=23}
                       ^
    SyntaxError: invalid syntax

    With Python 3.10.0b1, the comma is identified as the bad token:

    >>> ages = {'Alice'=22, 'Bob'=23}
      File "<stdin>", line 1
        ages = {'Alice'=22, 'Bob'=23}
                          ^
    SyntaxError: invalid syntax
    1. Example of incorrect error message

    Previously, we got the traditional and unhelpful "invalid syntax" but with the bad token identified correctly:

    >>> ages = {'Alice'=22}
      File "<stdin>", line 1
        ages = {'Alice'=22}
                       ^
    SyntaxError: invalid syntax

    With Python 3.10.0b1, we get the following:

    >>> ages = {'Alice'=22}
      File "<stdin>", line 1
        ages = {'Alice'=22}
                ^^^^^^^
    SyntaxError: cannot assign to literal here. Maybe you meant '==' instead of '='?

    I suspect that the ratio (== suggestion correct/ : suggestion correct) would be vanishingly small. ;-)

    @aroberge aroberge mannequin added 3.10 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) labels May 19, 2021
    @shreyanavigyan
    Copy link
    Mannequin

    shreyanavigyan mannequin commented May 19, 2021

    The bad token example needs a fix but the second is actually ok because we have another type we write within curly braces "{" and there the error is actually perfect. Like if we follow the error message, we use

    ages = {'Alice'==22}

    And we actually get a "set" with the first value as False. Sets behaves syntactically like list but have different behaviors of mathematical sets.

    @pablogsal
    Copy link
    Member

    I have an idea of what's causing the first one, but the second I am not sure we can detect easily we are in that case. Do you have a suggestion for what to place in the second case?

    @shreyanavigyan
    Copy link
    Mannequin

    shreyanavigyan mannequin commented May 19, 2021

    I'm don't the second is a problem at all. What the error message is suggesting is perfect since it doesn't know if we're trying to use a set or dict.

    @shreyanavigyan
    Copy link
    Mannequin

    shreyanavigyan mannequin commented May 19, 2021

    Sorry for the typos.

    @pablogsal
    Copy link
    Member

    I don't know, it think is more likely that people are triying to use the "=" as a ":" and constructing a literal. Is not a bad error, but I think is not the best one

    @shreyanavigyan
    Copy link
    Mannequin

    shreyanavigyan mannequin commented May 19, 2021

    Hmmm... Then is it possible to add an exception where the error message will result in,

    SyntaxError: cannot assign to literal here. Maybe you meant ':', "==" or ":=" instead of '='?

    only if we're dealing with curly braces?

    @aroberge
    Copy link
    Mannequin Author

    aroberge mannequin commented May 19, 2021

    In the second case, I understand very well that it could have been a set literal. In my (limited) experience, I have never seen a set literal containing a single element obtained from an == comparison.

    Since dict can be built by using keyword arguments, I tend to assume that using = in an literal that starts with { is meant to be a dict.

    In
    >>> ages = {'Alice' = 22}

    replacing the equal sign by either ==, :, or a comma would generate no SyntaxError. Clearly (in my mind anyway, and in previous Python versions), the "bad token" is the equal sign, and not the string Alice.

    Here's what I show with friendly:

    ======

    >> ages = {'Alice'=22}

    Traceback (most recent call last):
      File "<friendly-console:1>", line 1
        ages = {'Alice'=22}
                       ^
    SyntaxError: invalid syntax
    >>> why()

    It is possible that you used an equal sign = instead of a colon : to assign values to keys in a dict before or at the
    position indicated by ^.

    =====
    Admitedly, this suggestion could also be wrong - but the focus on this case (imo) should be on the "bad token" shown, which should be the equal sign.

    @pablogsal
    Copy link
    Member

    New changeset 07dba47 by Miss Islington (bot) in branch '3.10':
    bpo-44180: Report generic syntax errors in the furthest position reached in the first parser pass (GH-26253) (GH-26281)
    07dba47

    @miss-islington
    Copy link
    Contributor

    New changeset ae1732d by Miss Islington (bot) in branch '3.10':
    bpo-44180: Fix edge cases in invalid assigment rules in the parser (GH-26283)
    ae1732d

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @iritkatriel
    Copy link
    Member

    I think this is resolved, the error now is:

    ages = {'Alice'=22, 'Bob'=23}
    File "", line 1
    ages = {'Alice'=22, 'Bob'=23}
    ^^^^^^^
    SyntaxError: cannot assign to literal here. Maybe you meant '==' instead of '='?
    ages = {'Alice'=22}
    File "", line 1
    ages = {'Alice'=22}
    ^^^^^^^
    SyntaxError: cannot assign to literal here. Maybe you meant '==' instead of '='?

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.10 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants