classification
Title: f-string documentation not fully accurate
Type: Stage:
Components: Documentation Versions: Python 3.9, Python 3.8, Python 3.7, Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, eric.smith, v+python
Priority: normal Keywords:

Created on 2019-08-11 01:06 by v+python, last changed 2019-08-11 03:17 by xtreak.

Messages (1)
msg349370 - (view) Author: Glenn Linderman (v+python) * Date: 2019-08-11 01:06
I 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

If f-strings are processed AS DESCRIBED, the \n would never seen by the format expression... but in fact, it does produce an error.

PEP 498 has a more accurate description, that the {} parsing actually happens before the escape processing. The string or raw-string escape processing is done only to the literal string pieces.

So the string content is first parsed for format expressions enclosed in {}, on the way, converting {{ and }} to { and } in the literal parts of the string, and then the literal parts are treated exactly like independent string literals (with regular or raw-string escaping performed), to be concatenated with the evaluation of the format expressions, and subsequent literal parts.

The evaluation of the format expressions presently precludes the use of # and \ for comments and escapes, but otherwise tries to sort of by the same as a python expression possibly followed by a format mini-language part.  I am not the expert here, just the messenger.
History
Date User Action Args
2019-08-11 03:17:56xtreaksetnosy: + eric.smith
2019-08-11 01:06:41v+pythoncreate