[Python-ideas] String interpolation for all literal strings

Nick Coghlan ncoghlan at gmail.com
Thu Aug 6 07:23:23 CEST 2015


On 6 August 2015 at 06:03, Guido van Rossum <guido at python.org> wrote:
> We should look a bit more into how this proposal interacts with regular
> expressions (where \{ can be used to avoid the special meaning of {..}). I
> think \(..) would be more cumbersome than \{..}, since () is more common in
> regular expressions than {}.

Pondering the fact that "\N{GREEK LETTER ALPHA}",
"{ref}".format_map(data), f"\{ref}" and string.Template("${ref}") all
overload on "{}" as their parenthetical pair gave me an idea.

Since we're effectively defining a "string display" (which will
hopefully remain clearly independent of normal string literals), what
if we were to bake internationalisation and localisation directly into
this PEP, such that, by default, these new strings would be flagged
for translation, and translations could change the *order* in which
subexpressions were displayed, but not the *content* of those
subexpressions?

If we went down that path, then string.Template would provide the most
appropriate inspiration for the spelling, with "$" as the escape
character rather than "\". For regular expressions, the only
compatibility issue would be needing to double up on "$$" when
matching against the end of the input data.

Using "!" rather than "f" as the prefix, we could take advantage of
the existing (and currently redundant in Python 3) "u" prefix to mean
"untranslated":

    !"Message: $msg" <-- translated and interpolated text string (user messages)
    !u"Message: $msg" <-- untranslated and interpolated text string
(debugging, logging)
    !b"Message: $msg" <-- untranslated and binary interpolated byte sequence
    !r"Message: $msg" <-- disables "\" escapes, but not "$" escapes

The format strings after the ":" for the !b"${data:0.2f}" case would
be defined in terms of bytes.__mod__ rather than str.format

The reason I really like this idea is that combining automatic
interpolation with translation will help encourage folks to write
Python programs that are translatable by default, and perhaps have to
go back in later and mark some strings as untranslated, rather than
the status quo, where a lot of programs tend to be written on the
assumption they'll never be translated, so making them translatable
requires a significant investment of time to go through and build the
message catalog before translation can even begin.

Reviewing PEP 292, which introduced string.Template, further lead me
to take a 15 year trip in the time machine to Ka-Ping Yee's original
PEP 215: https://www.python.org/dev/peps/pep-0215/

That has a couple of nice refinements over the subsequent simpler PEP
292 interpolation syntax, in that it allows "$obj.attr.attr",
"$data[key]" and "$f(arg)" without requiring curly braces.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list