Because of the "invalid escape sequence" and "raw string" discussion, when looking at the documentation, I also noticed the following description for f-strings:
Escape sequences are decoded like in ordinary string literals (except when a literal is also marked as a raw string). After decoding, the grammar for the contents of the string is: followed by lots of stuff, followed by Backslashes are not allowed in format expressions and will raise an error: f"newline: {ord('\n')}" # raises SyntaxError
What I don't understand is how, if f-strings are processed AS DESCRIBED, how the \n is ever seen by the format expression. The description is that they are first decoded like ordinary strings, and then parsed for the internal grammar containing {} expressions to be expanded. If that were true, the \n in the above example would already be a newline character, and the parsing of the format expression would not see the backslash. And if it were true, that would actually be far more useful for this situation. So given that it is not true, why not? And why go to the extra work of prohibiting \ in the format expressions? The PEP 498, of course, has an apparently more accurate description, that the {} parsing actually happens before the escape processing. Perhaps this avoids making multiple passes over the string to do the work, as the literal pieces and format expression pieces have to be separate in the generated code, but that is just my speculation: I'd like to know the real reason. Should the documentation be fixed to make the description more accurate? If so, I'd be glad to open an issue. The PEP further contains the inaccurate statement:
Like all raw strings in Python, no escape processing is done for raw f-strings:
not mentioning the actual escape processing that is done for raw strings, regarding \" and \'.