On 8/23/2016 8:18 AM, Nick Coghlan wrote:
On 21 August 2016 at 03:32, Eric V. Smith <e...@trueblade.com> wrote:
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.
+1 for this if you can find a way to do it - it eliminates the
problematic cases where the order of evaluation makes a difference,
and ensures the parts within the braces can be reliably processed as
normal Python code.
I've been looking at this, and I agree it's the best thing to do, for
now (and possibly forever).
I'm just not convinced I can get it done before alpha 1. Assuming I can
get the coding done, I think I should update PEP 498 to say there can be
no backslashes inside the curly braces. That's my preferred outcome.
If I can't get it done by alpha 1, then I think the options are:
1. Leave f-strings as they are now, and that's how they'll always be.
2. Leave f-strings as they are now, but mark them as provisional and
warn people that the backslash restrictions will show up in an
upcoming release.
3. Disallow any backslashes anywhere in f-strings for 3.6, and relax the
restriction in 3.7 to make it only inside braces where the
restriction is enforced.
4. Remove f-strings from 3.6, and add them in 3.7 with the "no backslash
inside braces" restriction.
I'm not wild about 2: people will ignore this and will write code that
will break in 3.7. I'm also not wild about 3, since it's too restrictive.
I'm open to suggestions.
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/
