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

Guido van Rossum guido at python.org
Sun Aug 16 21:37:45 CEST 2015

On Sun, Aug 16, 2015 at 8:55 PM, Eric V. Smith <eric at trueblade.com> wrote:

> Thanks, Paul. Good feedback.

Indeed, I smiled when I saw Paul's post.

> Triple quoted and raw strings work like you'd expect, but you're right:
> the PEP should make this clear.
> I might drop the leading spaces, for a technical reason having to deal
> with passing the strings in to str.format. But I agree it's not a big deal
> one way or the other.

Hm. I rather like allow optional leading/trailing spaces. Given that we
support arbitrary expressions, we have to support internal spaces; I think
that some people would really like to use leading/trailing spaces,
especially when there's text immediately against the other side of the
braces, as in

  f'Stuff{ len(self.busy) }more stuff'

I also expect it might be useful to allow leading/trailing newlines, if
they are allowed at all (i.e. inside triple-quoted strings). E.g.

      }more stuff'''

> I'll incorporate the rest of your feedback (and others) when I get back to
> a real computer.

Here's another thing for everybody's pondering: when tokenizing an
f-string, I think the pieces could each become tokens in their own right.
Then the rest of the parsing (and rules about whitespace etc.) would become
simpler because the grammar would deal with them. E.g. the string above
would be tokenized as follows:

}more stuff'

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

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

More information about the Python-Dev mailing list