[Python-ideas] Let’s make escaping in f-literals impossible

Eric V. Smith eric at trueblade.com
Sat Aug 20 13:32:10 EDT 2016


On 8/19/2016 2:57 PM, Guido van Rossum wrote:
> I don't think we should take action now.
>
> Would it make sense, as a precaution, to declare the PEP provisional for
> one release? Then we can develop a sense of whether the current approach
> causes real problems.
>
> We could also emit some kind of warning if the expression part contains
> an escaped quote, since that's where a potential change would cause
> breakage. (Or we could leave that to the linters.)

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.

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

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.

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.

I also haven't thought of how this would affect raw f-strings.

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.

Eric.




More information about the Python-ideas mailing list