[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