Home Original page

[Python-ideas] Briefer string format

C Anthony Risinger anthony at xtfx.me
Thu Jul 23 06:05:27 CEST 2015 
On Jul 22, 2015 10:31 PM, "Steven D'Aprano" <steve at pearwood.info> wrote:
>
> [...]
>
> 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:
>
> msg = (f'a long message here blah blah {x}'
>         ' and {y} and {z} and more {stuff} and {things}'
>         ' and perhaps even more {poppycock}'
>        )
>
> should be exactly the same as the first version. My reasoning is that
> the implicit concatenation always occurs first, so by the time the
> format(...) magic occurs at run-time, the interpreter no long knows
> which braces came from an f-string and which came from a regular 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 avoid potential surprises, I would disallow the case where the f
> prefix doesn't occur in the first fragment, or at least raise a
> compile-time warning:
>
>     'spam' 'eggs' f'{cheese}'
>
> should raise or warn. (That restriction could be removed in the future,
> if it turns out not to be a problem.)
>
>
> > 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.

This makes perfect sense to me.

-- 

C Anthony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150722/2d8724e2/attachment.html>
More information about the Python-ideas mailing list