<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 16, 2015 at 8:55 PM, 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">Thanks, Paul. Good feedback.<br></blockquote><div><br></div><div>Indeed, I smiled when I saw Paul's post.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Triple quoted and raw strings work like you'd expect, but you're right: the PEP should make this clear.<br>
<br>
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.<br></blockquote><div><br></div><div>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<br><br></div><div><span style="font-family:monospace,monospace">  f'Stuff{ len(self.busy) }more stuff'</span><br><br></div><div>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.<br><br></div><div><span style="font-family:monospace,monospace">  f'''Stuff{<br></span></div><div><span style="font-family:monospace,monospace">      len(self.busy)<br></span></div><div><span style="font-family:monospace,monospace">      }more stuff'''</span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'll incorporate the rest of your feedback (and others) when I get back to a real computer.<br clear="all"></blockquote><div><br></div><div>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:<br><br></div><div><span style="font-family:monospace,monospace">f'Stuff{<br></span></div><div><span style="font-family:monospace,monospace">len<br>(<br></span></div><div><span style="font-family:monospace,monospace">self<br>.<br></span></div><div><span style="font-family:monospace,monospace">busy<br>)<br></span></div><div><span style="font-family:monospace,monospace">}more stuff'<br></span><br></div><div>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.)<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>