PEP 701 – Syntactic formalization of f-strings

[pablogsal (Pablo Galindo Salgado)]

Thanks a lot for the feedback @steven.daprano and thanks for taking the time to add some context to the explanations!

@steven.daprano

You describe f-strings as “literals” in the PEP. Please don’t do that. F-strings can contain executable code and can have side-effects. They are code not string literals.

We will correct this in the document soon.

@steven.daprano

The first two might be perfectly understandable to the parser, but as a human reader, they make it more complicated and error-prone to work out which quotes delimit the f-string and which do not.

Especially when the f-string may be concatenated with other strings, or embedded in larger expressions. Even more especially when used with long line lengths.

Taken in isolation, the human reader can just look at the start of the line and see the f" token, and then skip to the end of the line to find the matching close quote. But in real code, where f-strings are often embedded in complex expressions and long lines, it is not that easy. You have to manually parse the f-string, counting quotes and braces, and work out which ones are paired with which other ones.

You know. The sort of thing computers are excellent at but people suck at.

I consider the first two examples terrible code which should be discouraged and the fact that your PEP allows it is a point against it, not in favour.

Especially since we can get the same effect by just changing one of the pairs of quotes to '. So in this regard, the PEP doesn’t even add functionality. It just encourages people to write code which is harder to read and more error prone.

If I understand correctly your concern is that the nesting of the same kind of quote will make it harder for humans to parse and will lead to code that may be harder to read because the quote character is the same on start and end (as opposed to other delimiters). Would that summarise your concerns correctly?

@steven.daprano

Also keep in mind that many editors will have very simple-minded colourizers. Code inside f-strings may not be colourized, or if it is, the colourizer surely won’t include a full blown Python parser. So it will likely colour the first example as a comma-separated pair of strings:

Yes, this is being discussed currently in this thread and we will update the PEP after discussing about it.

Also notice that as I indicated before any editor that supports other popular languages including ruby and JavaScript will have the same problem as arbitrary nesting with quote reuse is allowed in those languages.