[Pablo]
*
The parser will allow nesting quote characters. This means
that we **could** allow reusing the same quote type in nested
expressions
like
this:
f"some
text { my_dict["string1"] } more text"
I'm okay with this, with the caveat that I raised in another email:
the effect on non-Python tools and alternate Python implementations.
To restate that here: as long as we survey some (most?) of the
affected parties and they're okay with it (or at least it doesn't
cause them a gigantic amount of work), then I'm okay with it. This
will of course be subjective. My big concern is tools that today use
regex's (or similar) to recognize f-strings, and then completely
ignore what's inside them. They just want to "skip over" f-strings
in the source code, maybe because they're doing some sort of
source-to-source transpiling, and they're just going to output the
f-strings as-is. It seems to me we're creating a lot of work for
such tools. Are there a lot of such tools? I don't know: maybe there
are none.
I assume this is primarily an issue for syntax highlighters, which must work under adverse conditions: the code may contain syntax errors nearby and they must update fast when the user is typing. (I recall these were the challenges when I implemented the first syntax coloring for IDLE several decades ago.)
If the syntax highlighter shows the wrong colors in an edge case, users can usually live with that. Something that just colors the entire f-string, including the interpolations, with the "string" color is not optimal anyways; the editor I currently use, VS Code, knows about f-strings and colorizes (and otherwise analyzes) the interpolations as expressions.
I imagine if you have a simple-minded highlighter that just uses a regex that matches string quotes, it will take something like my example and color it "string" until the first nested quote, then be confused for a bit, and then start coloring "string" after the second
nested quote, until the end of the f-string. So the confusion is local.
I created a gist with my example. This uses some well-known colorizer written in JavaScript (I presume). It seems to actually already support nested quotes?!
And here's a copy-paste from VS Code (it also shows a red underline under the entire f-string, but the copy doesn't show it):
def generate(source):
print("# What comes before")
print(f"{source.removesuffix(".py")}.c: $(srcdir)/{source}")
print("\t$(COMMAND)")
So these two tools, at least, seem to be doing all right (maybe because they both come from the JavaScript culture, where nested interpolations are well-known).