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

51–60 of 147 posts

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

#51

Post by ibraheemdev »

gh123man wrote: post #18

This reminds me of Swift's string formatting syntax: let name = "Bob" print("Hi my name is \(name)") Which I always quite liked. I found myself missing this when I moved on to Rust and Go.

The implicit formatting arguments RFC has been merged [0], so you will be able to write this in Rust soon:

  let name = "Bob";
  print!("Hello {name}");
[0]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-i...

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

#52

Post by theptip »

F-strings are great. The only downside I’ve found is they are incompatible with the stdlib logging framework’s deferred string interpolation feature (using %s style string interpolation), which can give you a nice performance boost if you make lots of expensive debug logs for tests, but run at info level in production.

That said most apps probably won’t see much of a difference in perf between the two approaches.

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

#53

Post by dmurray »

psalminen wrote: post #46
quietbritishjim wrote: post #7

Earlier quoted context omitted.

You can use any of f"{foo['field']}" f'{foo["field"]}' f"""{foo["field"]}""" (I see from your carefully worded first sentence that you already knew this but still find it annoying, but I'll leave this here for any that aren't aware.)

The problem with this is when you run it through a formatter that changes all ' to ".

Sounds like a bug in your formatter, if it's meant to just do formatting but actually replaces valid syntax with invalid.

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

#54

Post by climb_stealth »

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. And with that it becomes increasingly hard to work out what is actually being called. Now I resolved myself to pretty much just have one function call and no nesting. Things like f"{str.lower()}" or f"{hex(value)}" are great and I use them a lot.

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

#55

Post by foob »

nurpax wrote: post #4
noncoml wrote: post #2

I can't say I like the f" syntax much. I think JS's backtick is better. Other than that, I agree, much better than % and less verbose than .format. It's just the f" or f' that doesn't sit right with me

Yup, especially as you often need to access dict's with foo["field"] and you get a syntax error if the f-strings is also f"". JavaScript backtick syntax doesn't lead to this extra syntactic friction.

It can feel annoying sometimes, but it's also nice that it prevents you from getting overly complicated with your string interpolations. Human readability is highly valued in Python culture, and things start getting hard for humans to quickly parse when you allow arbitrarily complex interpolation expressions. Assigning your complicated expression to a well-named variable first will usually make your code more readable, even if it's slightly more verbose.

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

#56

Post by psalminen »

dmurray wrote: post #53
psalminen wrote: post #46

Earlier quoted context omitted.

The problem with this is when you run it through a formatter that changes all ' to ".

Sounds like a bug in your formatter, if it's meant to just do formatting but actually replaces valid syntax with invalid.

I don't totally disagree. My company uses the black formatter, which does this[0]. There are flags to skip string formatting, but is frowned upon at my organization.

[0] https://github.com/psf/black/blob/master/docs/the_black_code...

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

#57

Post by kzrdude »

ibraheemdev wrote: post #51
gh123man wrote: post #18

This reminds me of Swift's string formatting syntax: let name = "Bob" print("Hi my name is \(name)") Which I always quite liked. I found myself missing this when I moved on to Rust and Go.

The implicit formatting arguments RFC has been merged [0], so you will be able to write this in Rust soon: let name = "Bob"; print!("Hello {name}"); [0]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-i...

That's a surprise, I thought we were firmely against that. :)

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

#58

Post by cdrini »

ericvsmith wrote: post #40
noncoml wrote: post #2

I can't say I like the f" syntax much. I think JS's backtick is better. Other than that, I agree, much better than % and less verbose than .format. It's just the f" or f' that doesn't sit right with me

I've put together a proposal to have all strings be f-strings by default. Then you could drop the "f" prefix. I also propose adding a "p" prefix (for "plain") to remove the f-string parsing behavior. I talked about it at the last Python core sprint, and it only got lukewarm support, so I'm not sure I'm going to pursue it.

I would personally be quite against that. That's a pretty large breaking change, with no clear benefit. It doesn't make the feature more discoverable, since you still need to know that using "{}" will cause interpolation. I'd say net zero effect on readability; mostly just individual preference. And potential negative impact on performance.

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

#59

Post by kzrdude »

eachro wrote: post #29

This is super minor but I really wish f-string formatting were the default behavior for `print` or that there were a `printf` command just for it. Typing that extra f character before the quotes is just annoying enough

I just find the convergent evolution funny, that my C fingers that could type `printf()` fluently now learn to type `print(f"")` the same way

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

#60

Post by Blikkentrekker »

ericvsmith wrote: post #40
noncoml wrote: post #2

I can't say I like the f" syntax much. I think JS's backtick is better. Other than that, I agree, much better than % and less verbose than .format. It's just the f" or f' that doesn't sit right with me

I've put together a proposal to have all strings be f-strings by default. Then you could drop the "f" prefix. I also propose adding a "p" prefix (for "plain") to remove the f-string parsing behavior. I talked about it at the last Python core sprint, and it only got lukewarm support, so I'm not sure I'm going to pursue it.

Certainly this will lead to rather confused programmers.

F-strings certainly seem like opt-in behavior to me.

Post reply on HN