<p dir="ltr">On Jul 22, 2015 10:31 PM, "Steven D'Aprano" <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br>
><br>
> [...]<br>
><br>
> I would go further and allow all the f prefixes apart from the first to<br>
> be optional. To put it another way, the first f prefix "infects" all the<br>
> other string fragments:<br>
><br>
> msg = (f'a long message here blah blah {x}'<br>
>         ' and {y} and {z} and more {stuff} and {things}'<br>
>         ' and perhaps even more {poppycock}'<br>
>        )<br>
><br>
> should be exactly the same as the first version. My reasoning is that<br>
> the implicit concatenation always occurs first, so by the time the<br>
> format(...) magic occurs at run-time, the interpreter no long knows<br>
> which braces came from an f-string and which came from a regular string.<br>
><br>
> (Implicit concatenation is a compile-time operation, the format(...)<br>
> stuff is run-time, so there is a clear and logical order of operations.)<br>
><br>
> To avoid potential surprises, I would disallow the case where the f<br>
> prefix doesn't occur in the first fragment, or at least raise a<br>
> compile-time warning:<br>
><br>
>     'spam' 'eggs' f'{cheese}'<br>
><br>
> should raise or warn. (That restriction could be removed in the future,<br>
> if it turns out not to be a problem.)<br>
><br>
><br>
> > And merging f-strings:<br>
> > f'{foo}' f'{bar'}<br>
> > similarly just becomes concatenating the results of some function calls.<br>
><br>
> That's safe to do at compile-time:<br>
><br>
>   f'{foo}' f'{bar}'<br>
>   f'{foo}{bar}'<br>
><br>
> will always be the same. There's no need to delay the concat until after<br>
> the formats.</p>
<p dir="ltr">This makes perfect sense to me.</p>
<p dir="ltr">-- </p>
<p dir="ltr">C Anthony</p>