New submission from Glenn Linderman <v+pyt...@g.nevcal.com>:
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.
----------
assignee: docs@python
components: Documentation
messages: 349370
nosy: docs@python, v+python
priority: normal
severity: normal
status: open
title: f-string documentation not fully accurate
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue37816>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
