[Python-ideas] Briefer string format

[Bruce Leban]

On Wed, Jul 22, 2015 at 8:31 PM, Steven D'Aprano <steve at pearwood.info>
wrote:

>
> Constant-folding 'a' + 'b' to 'ab' is an optimization, it doesn't change
> the semantics of the concat. But constant-folding f'{a}' + '{b}' would
> change the semantics of the concatenation, because f strings aren't
> constants, they only look like them.
>

It doesn't have to change semantics and it shouldn't. This is a strawman
argument. While we could do it wrong, why would we? It's hardly difficult
to quote the non-format string while still optimizing the concatenation.

That is,
    f'{foo}' '{bar}' f'{oof}'
could compile to the same thing as if you wrote:
    f'{foo}{{bar}}{oof}'
the result of something like this:
    COMPILE_TIME_FORMAT_TRANSFORM('{foo}' + COMPILE_TIME_ESCAPE('{bar}') +
'{baz'})

This is analogous what happens with mixing raw and non-raw strings:
    r'a\b' 'm\n' r'x\y'
is the same as if you wrote:
    'a\\bm\nx\\y'
or
    r'''a\bm
    x\y'''

In the case of *implicit* concatenation, I think that the concatenations
> should occur first, at compile time. Yes, that deliberately introduces a
> difference between implicit and explicit concatenation, that's a
> feature, not a bug!
>

Doing the concatenation at compile time does NOT require the "infected"
behavior you describe below as noted above.


> I would go further and allow all the f prefixes apart from the first to
> be optional. To put it another way, the first f prefix "infects" all the
> other string fragments:
>
> I'd call that a bug. I suppose one person's bug is another person's
feature. It violates the principle of least surprise. When I look at a line
in isolation and it starts and ends with a quote, I would not expect that
to not just be a plain string.


> (Implicit concatenation is a compile-time operation, the format(...)
> stuff is run-time, so there is a clear and logical order of operations.)
>

To you, maybe. To the average developer, I doubt it. I view the compile
time evaluation of implicit concatenation as a compiler implementation
detail as it makes essentially no difference to the semantics of the
program. (Yes, I know that runtime concatenation *might* produce a
different string object each time through the code but it doesn't have to.
I hope you don't write programs that depend on the presence or absence of
string pooling.)

> And merging f-strings:
> > f'{foo}' f'{bar'}
> > similarly just becomes concatenating the results of some function calls.
>
> That's safe to do at compile-time:
>
>   f'{foo}' f'{bar}'
>   f'{foo}{bar}'
>
> will always be the same. There's no need to delay the concat until after
> the formats.


Just as it's safe to concat strings after escaping the non-format ones.

There is one additional detail. I think it should be required that each
format string stand on its own. That is:
    f'x{foo' f'bar}y'
should be an error and not the equivalent of
    f'x{foobar}y'

--- Bruce
Check out my new puzzle book: http://J.mp/ingToConclusions
<http://j.mp/ingToConclusions>
Get it free here: http://J.mp/ingToConclusionsFree
<http://j.mp/ingToConclusionsFree> (available on iOS)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150722/a485e5e9/attachment-0001.html>