[Python-ideas] String interpolation for all literal strings

Guido van Rossum guido at python.org
Fri Aug 7 11:37:27 CEST 2015


On Fri, Aug 7, 2015 at 11:03 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On Fri, Aug 7, 2015 at 1:49 AM, Guido van Rossum <guido at python.org> wrote:
> > On Fri, Aug 7, 2015 at 9:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>
> >> We could potentially make f-strings translation friendly by
> >> introducing a bit of indirection into the f-string design: an
> >> __interpolate__ builtin, along the lines of __import__.
> >
> >
> > This seems interesting, but doesn't it require sys._getframe() or similar
> > again? Translations may need to reorder variables. (Or even change the
> > expressions? E.g. to access odd plurals?)
> >
> > The sys._getframe() requirement (if true) would kill this idea thoroughly
> > for me.
>
> AFAICT sys._getframe is unneeded -- I understand Nick's suggestion to
> be that we desugar f"..." to:
>
>    __interpolate__("...", locals(), globals())
>
> with the reference to __interpolate__ resolved using the usual lookup
> rules (locals -> globals -> builtins).
>

sys._getframe() or locals()+globals() makes little difference to me -- it
still triggers worries that we now could be executing code read from the
translation database. The nice thing about f"{...}" or "\{...}" is that we
can allow arbitrary expressions inside {...} without worrying, since the
expression is right there for us to see. The __interpolate__ idea
invalidates that.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150807/177a9985/attachment.html>


More information about the Python-ideas mailing list