On 8/18/2016 3:30 PM, Steve Dower wrote:
On 18Aug2016 1215, Terry Reedy wrote:
On 8/18/2016 12:50 PM, Steve Dower wrote:
I don't think f'{x.partition('-')[0]}' is any less readable as a result
of the reused quotes,
Why are you reusing the single quote', which needs the escaping that you
don't like, instead of any of at least 6 alternatives that do not need
any escaping?
f'{x.partition("-")[0]}'
f'{x.partition("""-""")[0]}'
f"{x.partition('-')[0]}"
f'''{x.partition('-')[0]}'''
f"""{x.partition('-')[0]}"""
f"""{x.partition('''-''')[0]}"""
It seems to me that that this is at least somewhat a strawman issue.
If you want to prohibit backslashed quote reuse in expressions, as in
f'{x.partition(\'-\')[0]}', that is okay with me, as this is
unnecessary* and arguably bad. The third alternative above is better.
What breaks colorizers, and what I therefore object to, is the
innovation of adding magical escaping of ' or " without \.
Or add a new style rule to PEP 8.
F-strings: avoid unnecessary escaping in the expression part of f-strings.
Good: f"{x.partition('-')[0]}"
Bad: f'{x.partition(\'-\')[0]}'
Then PEP-8 checkers will flag such usage.
*I am sure that there are possible complex expressions that would be
prohibited by the rule that would be otherwise possible. But they
should be extremely rare and possibly not the best solution anyway.
I find it hard to not read f'{x.partition(' + ')[0]}' as string
concatenation.
That's a fair counter-example. Though f'{x.partition(\' + \')[0]}' still
reads like string concatenation to me at first glance. YMMV.
When the outer and inner quotes are no longer the same, the effect is
greatly diminished if not eliminated.
and it will certainly be easier for highlighters
to handle (assuming they're doing anything more complicated than simply
displaying the entire expression in a different colour).
Without the escapes, existing f-unaware highlighters like IDLE's will be
broken in that they will highlight the single f-string as two strings
with differently highlighted content in the middle. For
f'{x.partition('if')[0]}', the 'if' is and will be erroneously
highlighted as a keyword. I consider this breakage unacceptible.
Won't it be broken anyway because of the new prefix?
No. IDLE currently handles f-strings just fine other than not coloring
the 'f'. This is a minor issue and easily fixed by adding '|f' and if
allowed, '|F' at the end of the current stringprefix re.
I'm sure there's a fairly straightforward way for a regex to say that a
closing quote must not be preceded immediately by a backslash or by an
open brace at all without a closing brace in between.
I do not know that this is possible.
Here is IDLE's current re for an unprefixed single quoted string.
r"'[^'\\\n]*(\\.[^'\\\n]*)*'?"
The close quote is optional because it must match a string that is in
the process of being typed and is not yet closed. I consider providing
a tested augmented re to be required for this proposal.
Even then, making the parsing out of strings in Python code for
colorizing version dependent is a problem in itself for colorizers not
tied to a particular x.y version. Leaving prefixes aside, I can't
remember string delimiter syntax changing since I learned it in 1.3.
Not having escapes within the expression makes it harder for everyone
except the Python developer, in my opinion, and the rest of us ought to
go out of our way for them.
I am not sure that this says what you mean.
--
Terry Jan Reedy
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
