<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 7, 2015 at 11:03 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Aug 7, 2015 at 1:49 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Fri, Aug 7, 2015 at 9:33 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>><br>
>> We could potentially make f-strings translation friendly by<br>
>> introducing a bit of indirection into the f-string design: an<br>
>> __interpolate__ builtin, along the lines of __import__.<br>
><br>
><br>
> This seems interesting, but doesn't it require sys._getframe() or similar<br>
> again? Translations may need to reorder variables. (Or even change the<br>
> expressions? E.g. to access odd plurals?)<br>
><br>
> The sys._getframe() requirement (if true) would kill this idea thoroughly<br>
> for me.<br>
<br>
</span>AFAICT sys._getframe is unneeded -- I understand Nick's suggestion to<br>
be that we desugar f"..." to:<br>
<br>
   __interpolate__("...", locals(), globals())<br>
<br>
with the reference to __interpolate__ resolved using the usual lookup<br>
rules (locals -> globals -> builtins).<br></blockquote><div><br></div><div>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.<br></div></div><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>