
+1 for !r/!s and not being arbitrarily incompatible with existing formatting. (I also really like being able to align string literals using an f-string. That seems to come up all the time in my shorter scripts for headings etc.) Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Eric V. Smith<mailto:eric@trueblade.com> Sent: 8/1/2015 10:44 To: python-ideas@python.org<mailto:python-ideas@python.org> Subject: Re: [Python-ideas] Briefer string format On 7/25/2015 3:55 PM, Eric V. Smith wrote:
In trying to understand the issues for a PEP, I'm working on a sample implementation. There, I've just disallowed concatentation entirely. Compared to all of the other issues, it's really insignificant. I'll put it back at some point.
I'm basically done with my implementation of f-strings. I really can't decide if I want to allow adjacent f-string concatenation or not. I'm leaning towards not. I don't like mixing compile-time concatenation with run-time expression evaluation. But my mind is not made up. One issue that has cropped up: Should we support !s and !r, like str.format does? It's not really needed, since with f-strings you can just call str or repr yourself:
f'{"foo":10}' 'foo ' f'{repr("foo"):10}' "'foo' "
Do we also need to support:
f'{"foo"!r}' "'foo'"
With str.format, !s and !r are needed because you can't put the call to repr in str.format's very limited expression syntax. But since f-strings support arbitrary expressions, it's not needed. Still, I'm leaning toward including it for two reasons: it's concise, and there's no reason to be arbitrarily incompatible with str.format. If I include !s and !r, then the only way that str.format differs from f-string expressions is in non-numeric subscripting (unfortunate, but discussed previously and I think required). This ignores the fact that f-string expressions encompass all Python expressions, while str.format is extremely limited. I'll start working on the PEP shortly. Eric. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/