[Python-ideas] Let’s make escaping in f-literals impossible
Eric V. Smith
eric at trueblade.com
Mon Aug 29 17:16:16 EDT 2016
Oops, I meant beta 1 where I said alpha 1.
Eric.
On 8/29/2016 5:12 PM, Eric V. Smith wrote:
> On 8/23/2016 8:18 AM, Nick Coghlan wrote:
>> On 21 August 2016 at 03:32, Eric V. Smith <eric at 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.
>
More information about the Python-ideas
mailing list