[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