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

Eric V. Smith eric at trueblade.com
Mon Aug 10 20:37:12 CEST 2015


On 08/10/2015 02:31 PM, Barry Warsaw wrote:
> On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote:
> 
>> I think I would be happy with f-strings, or perhaps i-strings if we use
>> Nick's ideas about internationalisation, and limit what they can evaluate to
>> name lookups, attribute lookups, and indexing, just like format().
> 
> I still think you really only need name lookups, especially for an i18n
> context.  Anything else is just overkill, YAGNI, potentially error prone, or
> perhaps even harmful.
> 
> Remember that the translated strings usually come from only moderately (if at
> all) trusted and verified sources, so it's entirely possible that a malicious
> translator could sneak in an exploit, especially if you're evaluating
> arbitrary expressions.  If you're only doing name substitutions, then the
> worst that can happen is an information leak, which is bad, but won't
> compromise the integrity of say a server using the translation.
> 
> Even if the source strings avoid the use of expressions, if the feature is
> available, a translator could still sneak something in.  That pretty much
> makes it a non-starter for i18n, IMHO.
> 
> Besides, any expression you have to calculate can go in a local that will get
> interpolated.  The same goes for any !r or other formatting modifiers.  In an
> i18n context, you want to stick to the simplest possible substitution
> placeholders.

This is why I think PEP-498 isn't the solution for i18n. I'd really like
to be able to say, in a debugging context:

print('a:{self.a} b:{self.b} c:{self.c} d:{self.d}')

without having to create locals to hold these 4 values.

Eric.




More information about the Python-Dev mailing list