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

Stephen J. Turnbull stephen at xemacs.org
Tue Aug 11 09:33:43 CEST 2015

Barry Warsaw writes:

 > Besides, any expression you have to calculate can go in a local
 > that will get interpolated.

Sure, but that style should be an application programmer choice.

If this syntax can't replace the vast majority of cases where the
format method is invoked on a literal string without requiring
introduction of gratuitous temporaries, I don't see the point.  By
"invoked", I mean the arguments to the format method, too, so even
function calls should be permitted.  To me it's not worth the expense
of learning and teaching the differences otherwise.

If that point of view were generally accepted, it seems to me that it
kills this idea of using the same syntax for programmer interpolation
and for translation interpolation.  The two use cases present
requirements that are too different since translators are generally
"third party volunteers", *not* "trusted contributors".  Nor are their
contributions generally reviewed by "core".

 > In an i18n context, you want to stick to the simplest possible
 > substitution placeholders.

Certainly, and in that case I think format strings with simple
variable and attribute interpolation, plus an explicit invocation of
the format method comprise TOOWDTI -- it's exactly what you want!  In
fact, I am now -1 on an implicitly formatted I18N quasi-literal.  It
seems to me that in fact we should think of such an internationalized
string as merely an obfuscated way of spelling variable_input_by_user.
The current I18N frameworks make this clear by requiring a function
call, which theoretically could return any string and have any side
effects -- but these are controlled by the programmer.

But there are other contexts, equally important, where a more compact,
implicit formatting syntax would be very valuable, starting with

BTW, I know application programmers hate those calls.  I wonder if
they can't be folded into str.format, with a dummy string prefix of
"i" (or "_"!) being allowed solely to trigger xgettext and similar
potfile extraction utilities?  So you'd write

>>> s = i"Please translate this {adjective} string."
>>> s.format(adjective=i"beautiful", gettext=('ja', None))

where the first component of gettext is the language and the second is
the gettext domain (defaulting to the current application).  If that
works, the transformation from monolingual application to
internationalized application is sufficiently mechanical that a non-
programmer could be easily taught to perform it.

More information about the Python-Dev mailing list