[Python-Dev] PEP-498: Literal String Formatting

Eric V. Smith eric at trueblade.com
Sun Aug 9 20:22:43 CEST 2015

On 8/9/2015 1:38 PM, Brett Cannon wrote:
> On Sun, 9 Aug 2015 at 01:07 Stefan Behnel <stefan_ml at behnel.de
> <mailto:stefan_ml at behnel.de>> wrote:
>     Eric V. Smith schrieb am 08.08.2015 um 03:39:
>     > Following a long discussion on python-ideas, I've posted my draft of
>     > PEP-498. It describes the "f-string" approach that was the subject of
>     > the "Briefer string format" thread. I'm open to a better title than
>     > "Literal String Formatting".
>     >
>     > I need to add some text to the discussion section, but I think it's in
>     > reasonable shape. I have a fully working implementation that I'll get
>     > around to posting somewhere this weekend.
>     >
>     > >>> def how_awesome(): return 'very'
>     > ...
>     > >>> f'f-strings are {how_awesome()} awesome!'
>     > 'f-strings are very awesome!'
>     >
>     > I'm open to any suggestions to improve the PEP. Thanks for your
>     feedback.
>     [copying my comment from python-ideas here]
>     How common is this use case, really? Almost all of the string formatting
>     that I've used lately is either for logging (no help from this proposal
>     here) or requires some kind of translation/i18n *before* the formatting,
>     which is not helped by this proposal either. Meaning, in almost all
>     cases,
>     the formatting will use some more or less simple variant of this
>     pattern:
>         result = process("string with {a} and {b}").format(a=1, b=2)
>     which commonly collapses into
>         result = translate("string with {a} and {b}", a=1, b=2)
>     by wrapping the concrete use cases in appropriate helper functions.
>     I've seen Nick Coghlan's proposal for an implementation backed by a
>     global
>     function, which would at least catch some of these use cases. But it
>     otherwise seems to me that this is a huge sledge hammer solution for a
>     niche problem.
> So in my case the vast majority of calls to str.format could be replaced
> with an f-string. I would also like to believe that other languages that
> have adopted this approach to string interpolation did so with knowledge
> that it would be worth it (but then again I don't really know how other
> languages are developed so this might just be a hope that other
> languages fret as much as we do about stuff).

I think it has to do with the nature of the programs that people write.
I write software for internal use in a large company. In the last 13
years there, I've written literally hundreds of individual programs,
large and small. I just checked: literally 100% of my calls to
%-formatting (older code) or str.format (in newer code) could be
replaced with f-strings. And I think every such use would be an improvement.

I firmly believe that the majority of software written in Python does
not show up on PyPi, but is used internally in corporations. It's not
internationalized or localized: it just exists to get a job done
quickly. This is the code that would benefit from f-strings.

This isn't to say that there's not plenty of code where f-strings would
not help. But I think it's as big a mistake to generalize from my
experience as it is from Stefan's.


More information about the Python-Dev mailing list