On Wed, Jul 22, 2015 at 8:31 PM, Steven D'Aprano <steve@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)