
On 9/21/2021 3:29 PM, Guido van Rossum wrote:
On Tue, Sep 21, 2021 at 11:49 AM Eric V. Smith <eric@trueblade.com <mailto:eric@trueblade.com>> wrote:
[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 same-quote nesting were limited to 1 deep, REs could handle it. Since nesting is not, and same-quote nesting would not be, they cannot in general. f'''length is {len(3*f"{f'{a}'}")}''' 'length is 3' Still, if this arrives, I would consider a patch to handle the first nesting level.
If the syntax highlighter shows the wrong colors in an edge case, users can usually live with that.
Since IDLE is a gift, not a product, I've decided a feature falling short of perfection is OK.
Something that just colors the entire f-string, including the interpolations, with the "string" color is not optimal anyways;
To me, there is a tradeoff. Thunderbird bird displays the gmane version of the example below highlighted. I find the broken chunks to jarring.
the editor I currently use, VS Code, knows about f-strings and colorizes (and otherwise analyzes) the interpolations as expressions.
The red underline on the original display is a nice touch. It would definitely help to tie the whole string together. Assuming VS Code handles the double nesting, does it give two underlines for the example above, for the outer and middle strings?
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.
This is what IDLE does now.
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?! https://gist.github.com/gvanrossum/b8ca09175a0d1399a8999f13c7bfa616 <https://gist.github.com/gvanrossum/b8ca09175a0d1399a8999f13c7bfa616>
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).
With only 1 or even 2 types of quotes, reusing them would be more necessary than it is in Python. -- Terry Jan Reedy