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

[Wes Turner]

On Aug 10, 2015 4:52 PM, "Nathaniel Smith" <njs at pobox.com> wrote:
>
> On Aug 10, 2015 11:33 AM, "Barry Warsaw" <barry at python.org> 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.
>
> IIUC what Nick contemplates in PEP 501 is that when you write something
like
>   i"I am ${self.age}"
> 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
>   i"Tengo ${self.age} años"
> but
>   i"Tengo ${self.password} años"
> 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.
>
> 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...?

No, those remain; but minimizing calls to eval is good, too.

I prefer explicit template context for good reason:

* scope / variable binding in list comprehensions,
* "it was called 'cmd' two nested scopes ago"

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.

>
> -n
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150810/fcb1e1d8/attachment.html>