Changes to PEP 498 (f-strings)
After a long discussion on python-ideas (starting at https://mail.python.org/pipermail/python-ideas/2016-August/041727.html) I'm proposing the following change to PEP 498: backslashes inside brackets will be disallowed. The point of this is to disallow convoluted code like:
d = {'a': 4} f'{d[\'a\']}' '4'
In addition, I'll disallow escapes to be used for brackets, as in:
f'\x7bd["a"]}' '4'
(where chr(0x7b) == "{"). Because we're so close to 3.6 beta 1, my plan is to: 1. Modify the PEP to reflect these restrictions. 2. Modify the code to prevent _any_ backslashes inside f-strings. This is a more restrictive change than the PEP will describe, but it's much easier to implement. After beta 1, and hopefully before beta 2, I will implement the restrictions as I've outlined above (and as they will be documented in the PEP). The net effects are: a. Some code that works in the alphas won't work in beta 1. I'll document this. b. All code that's valid in beta 1 will work in beta 2, and some f-strings that are syntax errors in beta 1 will work in beta 2. I've discussed this issue with Ned and Guido, who are okay with these changes. The python-ideas thread I referenced above has some discussion about further changes to f-strings. Those proposals are outside the scope of 3.6, but the changes I'm putting forth here will allow for those additional changes, should we decide to make them. That's a discussion for 3.7, however. I'm sending this email out just to notify people of this upcoming change. I hope this won't generate much discussion. If you feel the need to discuss this issue further, please use the python-ideas thread (where some people are already ignoring it!). Eric.
I found some time before beta 1 to modify the f-string code to implement the desired behavior: no backslashes inside the curly braces, but they're allowed in the literal string portions. I just checked it in. I still need to update PEP 498, and the documentation needs updating. I'll create an issue for the docs once I've updated the PEP. This is a fairly large change, because now I need to parse the f-strings in UTF-8, and do the decoding myself in pieces, instead of the previous behavior of decoding the string first and then parsing it. I think I have tests for all of the backslash scenarios, but I'll watch the buildbots. Eric. On 8/30/2016 1:55 PM, Eric V. Smith wrote:
After a long discussion on python-ideas (starting at https://mail.python.org/pipermail/python-ideas/2016-August/041727.html) I'm proposing the following change to PEP 498: backslashes inside brackets will be disallowed. The point of this is to disallow convoluted code like:
d = {'a': 4} f'{d[\'a\']}' '4'
In addition, I'll disallow escapes to be used for brackets, as in:
f'\x7bd["a"]}' '4'
(where chr(0x7b) == "{").
Because we're so close to 3.6 beta 1, my plan is to:
1. Modify the PEP to reflect these restrictions. 2. Modify the code to prevent _any_ backslashes inside f-strings.
This is a more restrictive change than the PEP will describe, but it's much easier to implement. After beta 1, and hopefully before beta 2, I will implement the restrictions as I've outlined above (and as they will be documented in the PEP). The net effects are:
a. Some code that works in the alphas won't work in beta 1. I'll document this. b. All code that's valid in beta 1 will work in beta 2, and some f-strings that are syntax errors in beta 1 will work in beta 2.
I've discussed this issue with Ned and Guido, who are okay with these changes.
The python-ideas thread I referenced above has some discussion about further changes to f-strings. Those proposals are outside the scope of 3.6, but the changes I'm putting forth here will allow for those additional changes, should we decide to make them. That's a discussion for 3.7, however.
I'm sending this email out just to notify people of this upcoming change. I hope this won't generate much discussion. If you feel the need to discuss this issue further, please use the python-ideas thread (where some people are already ignoring it!).
Eric. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40tru...
Very happy to hear it. It's almost like you were present at the sprint! On Fri, Sep 9, 2016 at 7:04 PM, Eric V. Smith <eric@trueblade.com> wrote:
I found some time before beta 1 to modify the f-string code to implement the desired behavior: no backslashes inside the curly braces, but they're allowed in the literal string portions. I just checked it in.
I still need to update PEP 498, and the documentation needs updating. I'll create an issue for the docs once I've updated the PEP.
This is a fairly large change, because now I need to parse the f-strings in UTF-8, and do the decoding myself in pieces, instead of the previous behavior of decoding the string first and then parsing it.
I think I have tests for all of the backslash scenarios, but I'll watch the buildbots.
Eric.
On 8/30/2016 1:55 PM, Eric V. Smith wrote:
After a long discussion on python-ideas (starting at https://mail.python.org/pipermail/python-ideas/2016-August/041727.html) I'm proposing the following change to PEP 498: backslashes inside brackets will be disallowed. The point of this is to disallow convoluted code like:
d = {'a': 4} f'{d[\'a\']}'
'4'
In addition, I'll disallow escapes to be used for brackets, as in:
f'\x7bd["a"]}'
'4'
(where chr(0x7b) == "{").
Because we're so close to 3.6 beta 1, my plan is to:
1. Modify the PEP to reflect these restrictions. 2. Modify the code to prevent _any_ backslashes inside f-strings.
This is a more restrictive change than the PEP will describe, but it's much easier to implement. After beta 1, and hopefully before beta 2, I will implement the restrictions as I've outlined above (and as they will be documented in the PEP). The net effects are:
a. Some code that works in the alphas won't work in beta 1. I'll document this. b. All code that's valid in beta 1 will work in beta 2, and some f-strings that are syntax errors in beta 1 will work in beta 2.
I've discussed this issue with Ned and Guido, who are okay with these changes.
The python-ideas thread I referenced above has some discussion about further changes to f-strings. Those proposals are outside the scope of 3.6, but the changes I'm putting forth here will allow for those additional changes, should we decide to make them. That's a discussion for 3.7, however.
I'm sending this email out just to notify people of this upcoming change. I hope this won't generate much discussion. If you feel the need to discuss this issue further, please use the python-ideas thread (where some people are already ignoring it!).
Eric. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40tru...
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
participants (2)
-
Eric V. Smith -
Guido van Rossum