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.mo...@gmail.com> wrote: > >> On 8 August 2015 at 02:39, Eric V. Smith <e...@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@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 > _______________________________________________ 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/archive%40mail-archive.com