On Tue, Sep 21, 2021 at 11:49 AM Eric V. Smith <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 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?!
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).
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
> [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?!
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).
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
