Misleading SyntaxError on f-string

[Delengowski]

BPO	46260
Nosy	@ericvsmith, @lysnikolaou, @pablogsal, @williamnavaraj, @Delengowski

^{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 2022-01-05.13:23:29.218>
created_at = <Date 2022-01-04.20:31:12.570>
labels = ['interpreter-core', 'type-bug', '3.10']
title = 'Misleading SyntaxError on f-string'
updated_at = <Date 2022-01-05.16:43:18.141>
user = 'https://github.com/Delengowski'

bugs.python.org fields:

activity = <Date 2022-01-05.16:43:18.141>
actor = 'williamnavaraj'
assignee = 'none'
closed = True
closed_date = <Date 2022-01-05.13:23:29.218>
closer = 'eric.smith'
components = ['Parser']
creation = <Date 2022-01-04.20:31:12.570>
creator = 'Delengowski'
dependencies = []
files = []
hgrepos = []
issue_num = 46260
keywords = []
message_count = 6.0
messages = ['409709', '409723', '409752', '409762', '409764', '409784']
nosy_count = 5.0
nosy_names = ['eric.smith', 'lys.nikolaou', 'pablogsal', 'williamnavaraj', 'Delengowski']
pr_nums = []
priority = 'normal'
resolution = 'later'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46260'
versions = ['Python 3.10']

[Delengowski]

Example code

foo = 1
f"blank (open paren {foo )"

Error report

File "<stdin>", line 1
f"blank (open paren {foo )"
^
SyntaxError: f-string: unmatched ')'

The problem is due to unmatched '}' however.

[ericvsmith]

Simpler reproducer:

>>> f"{foo)"
  File "<stdin>", line 1
    f"{foo)"
            ^
SyntaxError: f-string: unmatched ')'

I assume this is the same error as:

>>> foo)
  File "<stdin>", line 1
    foo)
       ^
SyntaxError: unmatched ')'

But I don't yet understand why it's choosing to parse that expression fragment. I'm working on it.

[ericvsmith]

In fstring_find_expr, the code[0] that's checking for parens, braces, and brackets detects the closing paren without a matching open paren.

The error message isn't incorrect: if you added a matching open paren the code would compile:
>>> foo=lambda:0
>>> f'{foo()}'
'0'

So while the error might not be intuitive, it's not wrong.

0: https://github.com/python/cpython/blob/cae55542d23e606dde9819d5dadd7430085fcc77/Parser/string_parser.c#L664d

[Delengowski]

Hi Eric,

I see what are you referring to. Like you said unintuitive but still correct. Do you think it would be worthwhile to change the order of the checking such that '}' is always first? Or could the same edge case still appear but just the other way around?

Either way, thanks for looking into this and sorry for the trouble.

[ericvsmith]

No trouble. I'm glad to know it wasn't actually the same error as plain "foo)" (although the error message is the same). That would have concerned me.

Changing the code so that it doesn't error out on the first problem it sees, but keeps looking for a different type of error and then maybe backtracks or re-parses would be a lot of work, and I think we'd just end up with a different class of errors.

I'm going to close this. Maybe when/if we move f-strings to the real parser we can look at this issue again.

[williamnavaraj]

@eric Smith,Thanks for explaining the intuition behind this statement. I agree. Just to avoid ambiguity we could add

"f-string: unmatched '%c' - no matching open parenthesis or missing '}'"

The only possibility at nested_depth==0 line 665 is either of those because of the check in line 559 i.e. assert(**str == '{')

cpython/Parser/string_parser.c

Line 559 in cae5554

assert(**str == '{');

Will help folks to look backwards (close to open as well) than forwards (open to close) as in Matt's case which is also a valid interpretation where there is an opening paren outside the f-string.

or simply

"f-string: unmatched '%c' or missing '}'" will also do.