<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 17, 2015 at 7:13 AM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.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="">[...]</span><br>
My current plan is to replace an f-string with a call to .format_map:<br>
>>> foo = 100<br>
>>> bar = 20<br>
>>> f'foo: {foo} bar: { bar+1}'<br>
<br>
Would become:<br>
'foo: {foo} bar: { bar+1}'.format_map({'foo': 100, ' bar+1': 21})<br>
<br>
The string on which format_map is called is the identical string that's<br>
in the source code. With the exception noted in PEP 498, I think this<br>
satisfies the principle of least surprise.<br></blockquote><div><br></div><div>Does this really work? Shouldn't this be using some internal variant of format_map() that doesn't attempt to interpret the keys in brackets in any ways? Otherwise there'd be problems with the different meaning of e.g. {a[x]} (unless I misunderstand .format_map() -- I'm assuming it's just like .format(**blah).<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As I've said elsewhere, we could then have some i18n function look up<br>
and replace the string before format_map is called on it. As long as it<br>
leaves the expression text alone, everything will work out fine. There<br>
are some quirks with having the same expression appear twice, if the<br>
expression has side effects. But I'm not so worried about that.<span class=""><br></span></blockquote><div><br></div><div>The more I hear Barry's objections against arbitrary expressions from the i18n POV the more I am thinking that this is just a square peg and a round hole situation, and we should leave i18n alone. The requirements for i18n are just too different than the requirements for other use cases (i18n cares deeply about preserving the original text of the {...} interpolations; the opposite is the case for the other use cases).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
[...]<br>
> The understanding here is that there are these new types of tokens:<br>
> F_STRING_OPEN for f'...{, F_STRING_MIDDLE for }...{, F_STRING_END for<br>
> }...', and I suppose we also need F_STRING_OPEN_CLOSE for f'...' (i.e.<br>
> not containing any substitutions). These token types can then be used in<br>
> the grammar. (A complication would be different kinds of string quotes;<br>
> I propose to handle that in the lexer, otherwise the number of<br>
> open/close token types would balloon out of proportions.)<br>
<br>
</span>This would save a few hundred lines of C code. But a quick glance at the<br>
lexer and I can't see how to make the opening quotes agree with the<br>
closing quotes.<br></blockquote><div><br></div><div>The lexer would have to develop another stack for this purpose.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the i18n case (if we chose to support it) is better served by<br>
having the entire, unaltered source string available at run time. PEP<br>
501 comes to a similar conclusion<br>
(<a href="http://legacy.python.org/dev/peps/pep-0501/#preserving-the-unmodified-format-string" rel="noreferrer" target="_blank">http://legacy.python.org/dev/peps/pep-0501/#preserving-the-unmodified-format-string</a>).</blockquote><div><br></div><div>Fair enough. <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>