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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4