On Fri, Aug 19, 2016 at 6:09 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 19 August 2016 at 21:50, C Anthony Risinger <anth...@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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
