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

131–140 of 147 posts

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

#131

Post by qayxc »

akvadrako wrote: post #123
oxfordmale wrote: post #116

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…

I feel that python has been becoming less and less zen for a long time, starting with the async stuff and most recently with the walrus operator. I used to like it not because it was a great language but because it had a low barrier to entry for casual programmers. Now it's just like a worse Ruby with a lot of momentum from the early years.

I don't understand. Why exactly is having features that you don't need to use a barrier to entry?

Casual programmers can use the same Python that 2.x used - with very little (yet IMO logical) differences.

You can get started just as easily and use/learn (or don't) features as you need/wish.

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

#132

Post by qayxc »

oxfordmale wrote: post #116

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…

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

Yeah, and then - as the language matures - so do its users.

It's a common dilemma that cannot be fixed. You have the early adopters who grew up with the language and at some point got stuck in their ways (e.g. Python 2.x).

Replacing day-one features with new ones feels like using a new language to those who used the language for decades. The more mature (read: older and more widespread) a programming language becomes, the harder it is to introduce breaking changes.

String interpolation is one such area and due to the nature of the language such an important and integral part that it's becomes almost impossible to change.

As someone who never touched Python until very recently, I never even considered using anything but f-string formatting; I acknowledge that other (legacy) options exist, but outside of reading other people's code, I simply ignore them.

To new users who started with Python 3.x the obvious way to do it is f-strings and only language veterans switching to 3.x are affected by that feeling.

IMHO nothing changed. 2.x uses print without parentheses and the %-operator. 3.x requires parenthesis and prefers f-strings.

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

#133

Post by kevincox »

oxfordmale wrote: post #116

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…

I think this is actually improving the Zen of Python. Before my coworkers were pretty split between % and .format(). Now everyone uses fstrings. So while there is one more way to format strings now it seems that everyone has agreed that this is the "one correct way" to do it.

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

#134

Post by Majromax »

qayxc wrote: post #131
akvadrako wrote: post #123

Earlier quoted context omitted.

I feel that python has been becoming less and less zen for a long time, starting with the async stuff and most recently with the walrus operator. I used to like it not because it was a great language but because it had a low barrier to entry for casual programmers. Now it's just like a worse Ruby with a lot of momentum from the early years.

I don't understand. Why exactly is having features that you don't need to use a barrier to entry? Casual programmers can use the same Python that 2.x used - with very little (yet IMO logical) differences. You can get started just as easily and use/learn (or don't) features as you need/wish.

Casual programmers, especially those learning Python as a first programming language, aren't well-placed to know which language features they need. If they're learning from multiple sources and tutorial series A teaches Python 2-style %-formatting, B teaches str.format, and C teaches f-strings, then the novice programmer will learn all of these equivalent features.

This also shows up when the novice programmer wants to understand other people's code. If there is only one way to do things, then all common examples of a task should use that one way. If there are multiple ways (as here), then common examples (or an open source project of interest) may use any combination of them. To understand the code, the novice programmer needs to understand all of the right ways to do something rather than one of them.

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

#135

Post by dunefox »

kevincox wrote: post #133
oxfordmale wrote: post #116

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…

I think this is actually improving the Zen of Python. Before my coworkers were pretty split between % and .format(). Now everyone uses fstrings. So while there is one more way to format strings now it seems that everyone has agreed that this is the "one correct way" to do it.

It's the opposite of "only one obvious way to do it".

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

#136

Post by lightlyused »

ghshephard wrote: post #111
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

This was just an example to show what it does, I normally wouldn't have \h in a string. I use this to store lists of regular expressions in aws dynamodb list type and to convert them back to raw strings when used.

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

#137

Post by blueline »

climb_stealth wrote: post #54
rdtsc wrote: post #12

> However, once you start using several parameters and longer strings, your code will quickly become much less easily readable [...] `"Hello, %s %s. You are %s. You are a %s ...` Minor correction: % formatting allows specifying names for dictionary keys too: In [1]: "%(a)s and %(b)s" % {"a":"A", "b":"B"} Out[1]: 'A and B' In fact I had never switched to using str.format as it just never added enough benefit for me ov…

I have mixed feelings about code inside f-strings. It seems like a bit of a slippery slope towards losing track of what's happening. I have been tempted to write things like below because I really just need it for the print. f"Info print for item {hex(do_some_parsing(do_some_conversion(value)))}" Which runs perfectly fine, but at least on my editor syntax highlighting stops working as it is all part of the string. An…

PyCharm/intellij display the “code” part of f-strings similar to how a variable declaration or function call would be. I’m sure it’s possible for any other editors out there to apply some nicer formatting to f-strings as well.

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

#138

Post by zo1 »

mbeex wrote: post #128
zo1 wrote: post #117

Earlier quoted context omitted.

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.

> But for f-strings, it has full support for the "inline" variables. Is this complete (meaning: it also includes more complicated expressions, referencing these variables)? I'm asking, because some Python development tools are failing in doing it right. This leads to annoying reliability issues for refactorings (even for simple renames). Currently, I have the problem with Wing IDE.

As far as I know yes. It knows that the "usage" of that variable in an f-string is an actual reference to the variable vs just part of the string with the same set of characters.

Not sure what you mean by complicated expressions? If you mean the variable is referenced in a complicated statement with calcs or as part of a ternary operator, etc... AFAIK they are all supported. It even understands scope. So it won't go outside of the current scope where the variable is defined.

PyCharm's refactoring is very neat. In certain instances it even "refactors" relative paths inside a string if you move the file being referenced. Moving files around is intelligent and all imports get fixed. It has neat naming-convention renaming (myVariable->my_variable). Lots of nice little quality-of-life features, which is why I think it is the best Python IDE out there atm. Give it a whirl, it's got a free community edition that is near 100% functional!

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

#139

Post by jon_richards »

shakna wrote: post #73
stubish wrote: post #70

A wart is the standard logging module, which uses %-style strings. For example: log.debug("Unexpected, got %r", (got,)) By doing it this way, it can defer rendering the string until it is actually needed, which is (assumed to be) a win when the logging module is normally just going to toss the low level messages away rather than emit them anywhere. I think you lose this optimization if you use f-strings. I don't thin…

Whilst percent strings can't, calls to format can. So: log.debug("Unexpected, got {got}".format(got=got)) Or, to just use the available locals to automatically fill that in for you: log.debug("Unexepected, got {got}".format(**locals())) Or if you want both globals and locals with a preference for locals: log.debug("Unexepected, got {got}".format(**{**globals(), **locals()}))

Yes, I was asked by a Junior if they should always use f strings now. There are still a couple situations where you need format, such as when you’re formatting a variable instead of a literal.

Also, shoutout to Template for untrusted strings. It’s surprisingly unknown. Most people suggest replace or a custom format function.

Post reply on HN