[Python-Dev] PEP-498: Literal String Formatting

[Eric V. Smith]

Thanks, Paul. Good feedback.

Triple quoted and raw strings work like you'd expect, but you're right: the PEP should make this clear. 

I might drop the leading spaces, for a technical reason having to deal with passing the strings in to str.format. But I agree it's not a big deal one way or the other. 

I'll incorporate the rest of your feedback (and others) when I get back to a real computer. 

--
Eric.

Top-posted from my phone. 

> On Aug 16, 2015, at 10:21 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
>> On 8 August 2015 at 02:39, Eric V. Smith <eric at trueblade.com> wrote:
>> Following a long discussion on python-ideas, I've posted my draft of
>> PEP-498. It describes the "f-string" approach that was the subject of
>> the "Briefer string format" thread. I'm open to a better title than
>> "Literal String Formatting".
>> 
>> I need to add some text to the discussion section, but I think it's in
>> reasonable shape. I have a fully working implementation that I'll get
>> around to posting somewhere this weekend.
>> 
>>>>> def how_awesome(): return 'very'
>> ...
>>>>> f'f-strings are {how_awesome()} awesome!'
>> 'f-strings are very awesome!'
>> 
>> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
> 
> In my view:
> 
> 1. Calling them "format strings" rather than "f-strings" is sensible
> (by analogy with "raw string" etc). Colloquially we can use f-string
> if we want, but let's have the formal name be fully spelled out. In
> particular, the PEP should use "format string".
> 
> 2. By far and away the most common use for me would be things like
> print(f"Iteration {n}: Took {end-start) seconds"). At the moment I use
> str,format() for this, and it's annoyingly verbose. This would be a
> big win, and I'm +1 on the PEP for this specific reason.
> 
> 3. All of the complex examples look scary, but in practice I wouldn't
> write stuff like that - why would anyone do so unless they were being
> deliberately obscure? On the other hand, as I gained experience with
> the construct, being *able* to use more complex expressions without
> having to stop and remember special cases would be great.
> 
> 4. It's easy to write print("My age is {age}") and forget the "f"
> prefix. While it'll bug me at first that I have to go back and fix
> stuff to add the "f" after my code gives the wrong output, I *don't*
> want to see this ability added to unprefixed strings. IMO that's going
> a step too far (explicit is better than implicit and all that).
> 
> 5. The PEP is silent (as far as I can see) on things like whether
> triple quoting (f"""...""") is allowed (I assume it is), and whether
> prefixes can be combined (for example, rf'{drive}:\{path}\{filename}')
> (I'd like them to be, but can live without it).
> 
> 6. The justification for ignoring whitespace is weak (the motivating
> case is obscure, and there are many viable workarounds). I don't think
> it's worth ignoring whitespace - but I also don't think it's worth a
> long discussion. Just pick an option (as you did) and go with it. So I
> see no need for change here,
> 
> Apologies for the above being terse - I'm clearing a big backlog of
> emails. Ask for clarification if you need it!
> 
> Paul
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
>