On 8/14/2019 8:09 AM, Random832 wrote:
On Sat, Aug 10, 2019, at 19:54, Glenn Linderman wrote:
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?
AIUI there were strong objections to the "AS DESCRIBED" process (which would
require almost all valid uses of backslashes inside to be doubled, and would incidentally
leave your example *still* a syntax error), and disallowing backslashes is a way to
pretend that it doesn't work that way and leave open the possibility of changing how it
works in the future without breaking compatibility.
The only dubious benefit to the described process with backslashes allowed would be that f-strings (or other strings,
in the innermost level) could be infinitely nested as f'{f\'{f\\\'{...}\\\'}\'}', rather than being hard-limited to
four levels as f'''{f"""{f'{"..."}'}"""}'''
Sure. I am just pointing out (and did so in the issue I created for
documentation as well), that the documentation does not currently
correctly describe the implemenation, which is misleading to the user.
While I have opinions on how things could work better, my even stronger
opinion is that documentation should *accurately* describe how things
work, even if it how it works is more complex than it should be.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/B2HI27XRCA43GVV2D2MF5IZOUX5NG2PW/
