
On Fri, Aug 19, 2016 at 6:09 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 19 August 2016 at 21:50, C Anthony Risinger <anthony@xtfx.me> wrote:
The only real point I'm trying to make is that expressions within an f-string are an *escape*. They escape the normal semantics of a string literal and instead do something else for a while. Therefore, the escaped sections should not look like (or need to conform to) the rest of the string and they should not require quoting as if it were still within the string, because I escaped it already!
So, to me
f'{x.partition(' + ')[0]}'
reads as a string concatenation. I'm not sure how you'd expect a syntax highlighter to make it look like anything else, to be honest (given that you're arguing *not* to highlight the whole of the content of the f-string the same way).
The two string parts are string-colored and the x.partition bits would look like any other code in the file. It won't look like concatenation at that point. Examples referencing f'{one_expr_and_no_real_string_in_here}' feel somewhat crafted to confuse because the start and end quotes are directly adjacent to the expression. str(...) is the same complexity. Usage in the wild will have plenty of string-stuff on one or both sides, otherwise, why? Shell or Ruby code is probably more representative of how f-strings will be used. I know a couple people have mentioned they won't/don't care about highlighting in an f-string, but I honestly don't know a single person that would prefer this, except maybe one devops guy I know that does everything on old-school green text because why not. I've also spent hours and hours staring at--and sometimes editing--code on barebones servers/containers and I've come to respect the role colors play in my ability to quickly scan and read code.
The *real* solution is not to write something like this, instead write
f"{x.partition(' + ')[0]}"
Why? Why should I have to care what kind of quote I used at the start of the string? I thought I "escaped" the string at the `{` and now my brain has moved on to the expression? Am I still "inside" the string? etc... It's not the highlighting I care about per se, I think we have a small UX failure here. In a quality editor, everything about the {...} will tell me I'm writing a Python expression. It'll be colored like an expression. It'll do fancy completion like an expression. Aw shucks, it *IS* a Python expression! Except for one tiny detail: I'm not allowed to use the quote I use in 95% of all my Python code--without thinking--because I already used it at the string start :-( It's like this weird invisible ruh-roh-still-in-a-string state hangs over you despite everything else suggesting otherwise (highlighting and whatever fanciness helps people output code). The only time I personally use a different quote is when it somehow makes the data more amenable to the task at hand. The data! The literal data! Not the expressions I'm conveniently inlining with the help of f-strings. When I do it's a conscious decision and comes with a reason. Otherwise I'll use one type of quote exclusively (which depends on the lang, but more and more, it's simply doubles). The appeal of f-strings is the rapid inlining of whatever plus string data. "Whatever" is typically more complex than a simple attribute access or variable reference, though not much more complex eg. `object.method(key, "default")`. If I have to water it down for people to find it acceptable (such as creating simpler variables ahead-of-time) I'd probably just keep using .format(...). Because what I have gained with an f-string? The problem I have is the very idea that while inlining expressions I'm still somehow inside the string, and I have to think about that. It's not a *huge* overhead for an experienced, most-handsome developer such as myself, but still falls in that 5% territory (using a quote because I must vs. the one used 95%). Since f-string are fabulous, I want to use them all the time! Alas, now I have to think about flip-flopping quotes. I don't know what it's like to be taught programming but this seems like a possible negative interaction for new people (learning and using [one] quote combined with easy string building). I know it's not *that* big of deal to switch quotes. I believe this simpler implementation out the gate (not a dig! still great!) will come at the cost of introducing a small Python oddity requiring explanation. Not just because it's at odds with other languages, but because it's at odds with what the editor is telling the user (free-form expression). tl;dr, UX is weaker when the editor implies a free-form expression in every possible way, but the writer can't use the quote they always use, and I think strings will be common in f-string expression sections. -- C Anthony