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.

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.

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

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.

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.

@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 == '{')
https://github.com/python/cpython/blob/cae55542d23e606dde9819d5dadd7430085fcc77/Parser/string_parser.c#L559

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.