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

Rule name conflict and token marking mistakes in the 3.12.0rc grammar #109596

Closed
RobEin opened this issue Sep 20, 2023 · 2 comments
Closed

Rule name conflict and token marking mistakes in the 3.12.0rc grammar #109596

RobEin opened this issue Sep 20, 2023 · 2 comments
Assignees
Labels
3.12 bugs and security fixes 3.13 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@RobEin
Copy link

RobEin commented Sep 20, 2023

Bug report

Bug description:

This report was originally launched here.

grammars:
3.12.0rc3
3.13.0 alpha 0

Rule name conflict with the follwing two grammar rules:

fstring: star_expressions

and

fstring:
    | FSTRING_START fstring_middle* FSTRING_END

The colon sign is not a soft keyword (":"), it is a token (':') in these rules:

type_param:
    | NAME [type_param_bound] 
    | '*' NAME ":" expression 
    | '*' NAME 
    | '**' NAME ":" expression 
    | '**' NAME

type_param_bound: ":" expression

The equal sign is not a soft keyword ("="), it is a token ('=') in the following rule:

fstring_replacement_field:
    | '{' (yield_expr | star_expressions) "="? [fstring_conversion] [fstring_full_format_spec] '}'

These are more just notation problems in the previous two cases.
In general, this is a problem from that point of view that comparing two texts is slower than comparing two integers.

CPython versions tested on:

3.12

Operating systems tested on:

No response

Linked PRs

@RobEin RobEin added the type-bug An unexpected behavior, bug, or error label Sep 20, 2023
@sobolevn sobolevn added 3.12 bugs and security fixes 3.13 new features, bugs and security fixes labels Sep 20, 2023
@sobolevn sobolevn added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Sep 20, 2023
pablogsal added a commit to pablogsal/cpython that referenced this issue Sep 20, 2023
@pablogsal
Copy link
Member

pablogsal commented Sep 20, 2023

I created a PR to fix it, but notice is not really a problem as the parser does not generate soft keywords for these tokens. For example:

https://github.com/python/cpython/blob/850cc8d0b1db0a912a6e458720e265e6a6e5c1ba/Parser/parser.c#L15973

Regarding the repeated rule, is not a problem since is not really used anywhere. I will delete it in the PR

pablogsal added a commit to pablogsal/cpython that referenced this issue Sep 20, 2023
… and fix incorrect soft keywords

Signed-off-by: Pablo Galindo <pablogsal@gmail.com>
pablogsal added a commit that referenced this issue Sep 22, 2023
pablogsal added a commit to pablogsal/cpython that referenced this issue Sep 22, 2023
…allowed and fix incorrect soft keywords (pythonGH-109606).

(cherry picked from commit b28ffaa)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
csm10495 pushed a commit to csm10495/cpython that referenced this issue Sep 28, 2023
Yhg1s pushed a commit that referenced this issue Oct 2, 2023
…d and fix incorrect soft keywords (GH-109606). (#109752)

(cherry picked from commit b28ffaa)
@lysnikolaou
Copy link
Contributor

This has been fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.12 bugs and security fixes 3.13 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

4 participants