Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3's F-Strings: An Improved String Formatting Syntax

realpython.com

Post reply on HN
Print view View original

111–120 of 147 posts

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#111

Post by ghshephard »

lightlyused wrote: post #69

I love f-strings. Don't forget that you can do fr"some string {blah}" to build raw strings. >>> blah = "something \here" >>> fr"what the {blah}" 'what the something \\here'

What version of python are you using. With python 3.8.5

1. \h doesn't get interpolated to anything (unlike \a, \b, \f, etc...)

   "\h"
   '\\h'
   
   "\a"
   '\x07'
2. The "r" needs to be in the original definition, not the f-string.

    blah = r"\a"
You only need the "r" in the f-string if you don't want interpoolation of the "\" - I.e.:

   fr" this\a {blah}"
   'This\\a \\a

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#112

Post by mybrid »

What if one is printing the output of a function? Then one is left with reverting to positional formats. Mixing positional and named formats is less than robust. One of the common cases for function output is using pprint. As someone who has been using Python since 2.4 print formating using pprint is robust. Over the years I've found it a best practice to only use positional formatting so as to have the format string be stable when switching between usuing a variable or pprint of the variable, especially when debugging. So, I am not using f strings. Another thing is that as a decades long PERL developer I observe Python is becoming the new PERL in having fifty ways to do something. All of these ways will have small-to-large performance differences. Because of this then soon we will all have the Python Cookbook on our shelves to document them so one knows when to part ways with less optimal usages. It is always faster to print an unformatted list then a format string and in fact pylint will ding your code if logger uses a format string and not a list of strings and variables in print order. Then one begins to wonder if this is the case for logger then why not for every print statement? And thus Python is quickly degenerating into PERL code readable territory with each new version.

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#113

Post by mckirk »

mybrid wrote: post #112

What if one is printing the output of a function? Then one is left with reverting to positional formats. Mixing positional and named formats is less than robust. One of the common cases for function output is using pprint. As someone who has been using Python since 2.4 print formating using pprint is robust. Over the years I've found it a best practice to only use positional formatting so as to have the format string…

Why wouldn't you be able to use f-strings to print function output?

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#114

Post by gitanovic »

japhyr wrote: post #44

I learned this nice syntax from a tweet yesterday: >>> import datetime >>> now = datetime.datetime.now() >>> f"Today is {now:%m/%d/%Y}." 'Today is 01/20/2021.' No need for now.strftime() in simple string output! https://twitter.com/mariatta/status/1351359518316216321

While I really do like this, I cannot avoid remarking that python starts to look more and more like perl

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#116

Post by oxfordmale »

I do love the Python F-string syntax, however, it shows a weakness of Python as it has been maturing over the years. The original Zen of Python was (PEP 20)

There should be one-- and preferably only one --obvious way to do it.

There are many ways to format a string, and F-Strings are yet another way. String formatting is not the only area where the original ZEN no longer applies. Of course this is part of a language natural evolution, however, it does make the language more confusing for new starters. Syntax sugar coating Python may also distract from solving more systematic problems, like the lack of proper multithreading in Python.

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#117

Post by zo1 »

pfranz wrote: post #104
dec0dedab0de wrote: post #48

I found out about f strings from an HN comment a few years ago. Ever since I have been super excited to show people who don't know about them. In Python 2 I used to use .format(**locals()) which is basically the same thing, but felt like a hack.

I saw this a few years ago and thought it was cool at first, but I had huge problems when refactoring that code. I would miss variables used in strings when I would rename, move, or delete things. Have you had this issue? I imagine an IDE that could grok it would have helped.

Pycharm "refactor" for variables has the option to search for the variable-name being changed in comments and strings.

But for f-strings, it has full support for the "inline" variables.

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#118

Post by [deleted] »

pfranz wrote: post #104
dec0dedab0de wrote: post #48

I found out about f strings from an HN comment a few years ago. Ever since I have been super excited to show people who don't know about them. In Python 2 I used to use .format(**locals()) which is basically the same thing, but felt like a hack.

I saw this a few years ago and thought it was cool at first, but I had huge problems when refactoring that code. I would miss variables used in strings when I would rename, move, or delete things. Have you had this issue? I imagine an IDE that could grok it would have helped.

[deleted]

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#119

Post by dnautics »

psychoslave wrote: post #35

So far Ruby provided me the best user experience regarding string interpolation, and it owes a large part of it to Perl. Squiggly heredoc is something I am unaware of in any other general programming language.

Elixir heredocs do this by default. Plus you can prepend it with sigils to activate string macros. Here I use it to inject content into another programming language embedded within Elixir (lower case ~z allows interpolation, upper case ~Z does not):

https://www.youtube.com/watch?v=fIxNEILcNGM&t=25m50s

Re: Python 3's F-Strings: An Improved String Formatting Syntax

#120

Post by dec0dedab0de »

ericvsmith wrote: post #64
dec0dedab0de wrote: post #48

I found out about f strings from an HN comment a few years ago. Ever since I have been super excited to show people who don't know about them. In Python 2 I used to use .format(**locals()) which is basically the same thing, but felt like a hack.

The more efficient version of this is .format_map(locals())

I didnt know format_map existed, but it looks like it is not in python 2 so it wouldn't have helped in that use case. Still, thanks for pointing that out. I love learning about new minor conveniences in Python.
Post reply on HN