<p dir="ltr"><br>
On Aug 10, 2015 4:52 PM, "Nathaniel Smith" <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
><br>
> On Aug 10, 2015 11:33 AM, "Barry Warsaw" <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
> ><br>
> > On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote:<br>
> ><br>
> > >I think I would be happy with f-strings, or perhaps i-strings if we use<br>
> > >Nick's ideas about internationalisation, and limit what they can evaluate to<br>
> > >name lookups, attribute lookups, and indexing, just like format().<br>
> ><br>
> > I still think you really only need name lookups, especially for an i18n<br>
> > context.  Anything else is just overkill, YAGNI, potentially error prone, or<br>
> > perhaps even harmful.<br>
> ><br>
> > Remember that the translated strings usually come from only moderately (if at<br>
> > all) trusted and verified sources, so it's entirely possible that a malicious<br>
> > translator could sneak in an exploit, especially if you're evaluating<br>
> > arbitrary expressions.  If you're only doing name substitutions, then the<br>
> > worst that can happen is an information leak, which is bad, but won't<br>
> > compromise the integrity of say a server using the translation.<br>
> ><br>
> > Even if the source strings avoid the use of expressions, if the feature is<br>
> > available, a translator could still sneak something in.  That pretty much<br>
> > makes it a non-starter for i18n, IMHO.<br>
> ><br>
> > Besides, any expression you have to calculate can go in a local that will get<br>
> > interpolated.  The same goes for any !r or other formatting modifiers.  In an<br>
> > i18n context, you want to stick to the simplest possible substitution<br>
> > placeholders.<br>
><br>
> IIUC what Nick contemplates in PEP 501 is that when you write something like<br>
>   i"I am ${self.age}"<br>
> then the python runtime would itself evaluate self.age and pass it on to the i18n machinery to do the actual substitution; the i18n machinery wouldn't even contain any calls to eval. The above string could be translated as<br>
>   i"Tengo ${self.age} años"<br>
> but<br>
>   i"Tengo ${self.password} años"<br>
> would be an error, because the runtime did not provide a value for self.password. So while arbitrarily complex expressions are allowed (at least as far as the language is concerned -- a given project or i18n toolkit could impose additional policy restrictions), by the time the interpolation machinery runs they'll effectively have been reduced to local variables with funny multi-token names.<br>
><br>
> This pretty much eliminates all the information leak and exploit concerns, AFAICT. From your comments about having to be careful about attribute chasing, it sounds like it might even be more robust than current flufl.i18n in this regard...?</p>
<p dir="ltr">No, those remain; but minimizing calls to eval is good, too.</p>
<p dir="ltr">I prefer explicit template context for good reason:</p>
<p dir="ltr">* scope / variable binding in list comprehensions,<br>
* "it was called 'cmd' two nested scopes ago"</p>
<p dir="ltr">Again, convenient but dangerous (Django and Jinja can/do autoescaping) and making it far too easy to wrongly quote and not escape strings (which often contain domain-specific) control characters.<br><br></p>
<p dir="ltr">><br>
> -n<br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com">https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com</a><br>
><br>
</p>