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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
