[Python-ideas] Draft PEP on string interpolation

[Eric V. Smith]

On 08/26/2015 10:51 AM, Ron Adam wrote:
> On 08/26/2015 07:56 AM, Eric V. Smith wrote:
>> I think your example below is a functional subset of what I have on
>> bitbucket. The only real distinction is that I can do substitutions from
>> a different string, using the expressions that were originally evaluated
>> when the i-string was constructed. This is needed for the i18n case. I
>> realize i18n might never use this, but it's a useful thought experiment
>> in any case.
> 
> In my example... the literal and value parts of the strings are stored
> as strings in two different lists, so you can still apply an i18n
> translator to just the literal parts, or to the value parts, or to both.
>  It just needs another method.  If it's done as a property it could be
> spelled...
> 
>    s = 'string'
>    i'This {s} will be translated'._

I still think the i18n case is off the table, per Barry. But in any
event, you can't translate the literals in pieces. I think you need to
design something that works with gettext. Since the part of my design
that allows this is just an optional parameter to my i.join() method,
there's not much cost. I do scan the string again, but that would likely
be optimized away in a C version.

> A nice improvement to that would be to add a literal quote ability to
> the format language.
> 
>   i'This {"string":Q} will be translated'.+

That would just work, without the :Q. Expressions cannot be translated,
and "string" is an expression.

> It allows marking parts of a string to not translate without needing to
> set it an external (to the string) variable as the example above does.
> Adding a raw quote option, RQ, would help in the cases of html and
> regular expressions.  (as your's does), but it seems this would be a
> good addition to the format language so it would work with regular
> strings too.
> 
> 
> I don't have time to test yours this morning, but What happens in this
> case?
> 
>     x = [1]
>     ix = i('{x}')
>     x = [2]          # Mutates i-string content?
>     print(str(ix))
> 
> Does this print "[1]" or "[2]"?

I added a similar test this morning. My code produces "[2]". I can't
imagine a design that could produce a different result, but follow the
"delayed evaluation of the string" model.

Eric.