The f-string grammar clearly specifies the correct order of f-string =, !, and : specifiers:

replacement_field ::=  "{" f_expression ["="] ["!" conversion] [":" format_spec] "}"

However, when these components are used in the wrong order, the error messages, while understandable if you know the grammar, are not exactly helpful for users of all knowledge levels.


>>> foo = 12.345
>>> f'{foo=:.2f}'  # correct ordering of = and :
'foo=12.35'
>>> f'{foo:.2f=}'  # incorrect ordering of : and =
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier
>>> f'{foo=!r}'    # correct ordering of = and !
'foo=12.345'
>>> f'{foo!r=}'    # incorrect ordering of ! and =
  File "<stdin>", line 1
SyntaxError: f-string: expecting '}'
>>> bar = 'abcd'
>>> f'{bar!r:.2s}' # correct ordering of ! and :
"'a"
>>> f'{bar:.2s!r}' # incorrect ordering of : and !
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier


It would be more helpful to have more descriptive error messages specifying the correct order of these features. f-string format specifiers, especially ! and =, are in my experience fairly poorly known features, and more descriptive feedback when they are used incorrectly would avoid discouraging users from using them at all upon encountering a cryptic error. 

Since __format__ can have an arbitrary implementation for different data types, and therefore there might be some user-defined class that accepts :.2f!r as a valid format specifier, the ValueErrors here might have to stay, but at least the SyntaxError from f'{foo!r=}' could be clearer.

As you note, some of these likely cannot be improved.

There was talk last year about moving f-string's bespoke lexer/parser/compiler into the normal Python grammar. But I'm not sure if that ever got anywhere. If we did make that change, it would be easier to improve the error messages. Well, at least as easy as improving normal Python error messages.

I could try to give it a go to this still with the current parser, I think we could have some improvements without a lot of refactoring.

Moving the whole f string to the grammar still don't ensure making this work easier unfortunately because is not clear how much backtracking the parser will require. When it requires enough backtracking, adding errors can be a pain.