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

[Guido van Rossum]

On Mon, Aug 17, 2015 at 7:13 AM, Eric V. Smith <eric at trueblade.com> wrote:

> [...]
> My current plan is to replace an f-string with a call to .format_map:
> >>> foo = 100
> >>> bar = 20
> >>> f'foo: {foo} bar: { bar+1}'
>
> Would become:
> 'foo: {foo} bar: { bar+1}'.format_map({'foo': 100, ' bar+1': 21})
>
> The string on which format_map is called is the identical string that's
> in the source code. With the exception noted in PEP 498, I think this
> satisfies the principle of least surprise.
>

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).

>
> As I've said elsewhere, we could then have some i18n function look up
> and replace the string before format_map is called on it. As long as it
> leaves the expression text alone, everything will work out fine. There
> are some quirks with having the same expression appear twice, if the
> expression has side effects. But I'm not so worried about that.
>

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).


> [...]
> > The understanding here is that there are these new types of tokens:
> > F_STRING_OPEN for f'...{, F_STRING_MIDDLE for }...{, F_STRING_END for
> > }...', and I suppose we also need F_STRING_OPEN_CLOSE for f'...' (i.e.
> > not containing any substitutions). These token types can then be used in
> > the grammar. (A complication would be different kinds of string quotes;
> > I propose to handle that in the lexer, otherwise the number of
> > open/close token types would balloon out of proportions.)
>
> This would save a few hundred lines of C code. But a quick glance at the
> lexer and I can't see how to make the opening quotes agree with the
> closing quotes.
>

The lexer would have to develop another stack for this purpose.


> I think the i18n case (if we chose to support it) is better served by
> having the entire, unaltered source string available at run time. PEP
> 501 comes to a similar conclusion
> (
> http://legacy.python.org/dev/peps/pep-0501/#preserving-the-unmodified-format-string
> ).


Fair enough.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150817/82ca6a01/attachment.html>