<p dir="ltr">On Aug 20, 2016 1:32 PM, "Eric V. Smith" <<a href="mailto:eric@trueblade.com">eric@trueblade.com</a>> wrote:<br>
><br>
> On 8/19/2016 2:57 PM, Guido van Rossum wrote:<br>
>><br>
>> I don't think we should take action now.<br>
>><br>
>> Would it make sense, as a precaution, to declare the PEP provisional for<br>
>> one release? Then we can develop a sense of whether the current approach<br>
>> causes real problems.<br>
>><br>
>> We could also emit some kind of warning if the expression part contains<br>
>> an escaped quote, since that's where a potential change would cause<br>
>> breakage. (Or we could leave that to the linters.)<br>
><br>
><br>
> If anything, I'd make it an error to have any backslashes inside the brackets of an f-string for 3.6. We could always remove this restriction at a later date.<br>
><br>
> I say this because as soon as f-strings make it into the wild, we're going to have a hard time breaking code in say 3.7 by saying "well, we told you that f-strings might change".<br>
><br>
> Although frankly, other than be executive fiat (which I'm okay with), I don't see us ever resolving the issue if f-strings are strings first, or if the brackets put you into "non-string mode". There are good arguments on both sides.<br>
><br>
> Moving to the implementation details, I'm not sure how easy it would be to even find backslashes, though. IIRC, backslashes are replaced early, before the f-string parser really gets to process the string. It might require a new implementation of the f-string parser independent of regular strings, which I likely would not have time for before beta 1. Although since this would be a reduction in functionality, maybe it doesn't have to get done by then.<br>
><br>
> I also haven't thought of how this would affect raw f-strings.<br>
><br>
> In any event, I'll take a look at adding this restriction, just to get an estimate of the magnitude of work involved. The easiest thing to do might be to disallow backslashes in any part of an f-string for 3.6, although that seems to be going too far.<br>
><br>
><br>
> Eric.</p>
<p dir="ltr">Speaking of which, how is this parsed?<br>
        f"{'\n'}"<br>
If escape-handling is done first, the expression is a string literal holding an actual newline character (normally illegal), rather than an escape sequence which resolves to a newline character.</p>
<p dir="ltr">If that one somehow works, how about this?<br>
        f"{r'\n'}"</p>
<p dir="ltr">I guess you'd have to write one of these:<br>
        f"{'\\n'}"<br>
        f"{'''\n''')"<br>
        rf"{'\n'}"</p>