[Python-ideas] Fix the DRY problem (was Re: PEP 501 - i18n with marked strings)

[Barry Warsaw]

On Aug 15, 2015, at 08:27 AM, Eric V. Smith wrote:

>We instead translate it to:
>__i18n__("My name is {name}, my dog's name is
>{dog_name}").format_map({'name':'Eric', 'dog_name':'Fluffy')
>
>The string would be unchanged from value of the f-string. The keys in
>the dict would be exactly the expressions inside the braces in the
>f-string. The values in the dict would be the value of the expressions
>in the f-string.

+1

>We could add something like's PEP 501's iu-strings, that would be
>interpolated but not translated, so we could mix translated and
>non-translated strings in the same module. Probably not spelled
>fu-strings, though!

One of the things I've mentioned to Nick about PEP 501 is the difference
between i"foo" and iu"foo".  The former gets mapped to __interpolate__() while
the latter gets mapped to __interpolateu__().  Nick makes the case for this
distinction based on the ability to override __interpolate__() in the local
namespace to implement i18n, whereas __interpolateu__() - while technically
still able to override - would generally just be left to the "normal" non-i18n
interpolation.

I countered with a proposal that a context manager could be used, but Nick
points out that you can't really *unbind* __interpolate__() when the context
manager exits.

This still seems weird to me.  There's no distinction in Python 3 between
"foo" and u"foo" with the latter having been re-added to aid in migrations
between Python 2 and 3.  But with PEP 501, this introduces a functional
distinction between i"foo" and iu"foo" (and ui"foo"?).  It's handy, but seems
to be a fairly significant difference from the current use if u-prefixes.  I'm
sympathetic but still skeptical. ;)

>We'd probably want to add a str.safe_format_map to match the behavior of
>string.Template.safe_substitute, or add a parameter to str.format_map.  I'm
>not sure how this parameter would get set from an f-string, or if it would
>always default to "safe" for the __i18n__ case.
>
>Maybe instead of __i18n__ just doing the string lookup, it would also be
>responsible for calling .format_map or .safe_format_map, so it could choose
>the behavior it wanted on a per-module basis.

You always want safe-substitution for i18n because you can't let broken
translations break your application (i.e. by causing exceptions to be
thrown).  It's the lesser of two evils to just include the original,
un-interpolated placeholder in the final string.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150817/e9f5bae8/attachment.sig>