On Mon, Jun 29, 2020 at 05:29:31PM +0300, Mikhail V wrote:
Proposal:
Allow standard python escapes inside curly braces in f-strings. Main point is to make clear visual distinction between text and escaped chars:
There is already a clear visual distinction between text and escaped chars: escaped chars begin with a backslash. Plain text does not. So your proposal adds a second way to put escaped characters inside f-strings, but not regular strings: f"{x}\n" == f"{x}{\n}" What you are adding is confusion between escaped chars and executable expressions, since both will be surrounded by curly brackets: # proposed syntax f"text here {expression}" f"text here {\n}" Unlikely as it might be, there is still a chance that some day we might add a backslash unary operator `\x`. This proposal would shut the door to that possibility, since `f"{\n}"` would then be ambiguous. For single-character escape codes, I see no benefit at all to this, only disadvantages. However I do see a tiny potential benefit to hex escapes, for the rare occassions that they are immediately followed by something that looks like it could be part of the escape but isn't: "\x2b2c" # Looks like '+,' but is '+2c' Notice that this occurs for regular strings too, so a f-string only proposal is not justified. Fix it for both or for neither, don't introduce an inconsistency. Counter-proposal: hex escapes allow optional curly brackets, similar to unicode name escapes. You could even allow spaces within the braces, for grouping: # Existing: "\N{HYPHEN-MINUS}" # '-' "\x2b" # '+' # Proposed enhancement: "\x{2b}2c" # '+2c' "\x{2b2c}" # '+,' "\x{DEAD BEEF}" # "\xDE\xAD\xBE\xEF" This could work in f-strings and bytes as well. I think this might be of use for people who do a lot of work with binary file formats and hex escapes. I think this is backwards compatible too, since "\x{" is currently a syntax error. -- Steven