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

61–70 of 147 posts

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

#61

Post by nimih »

psalminen wrote: post #56
dmurray wrote: post #53

Earlier quoted context omitted.

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...

For what it's worth, black appears to do a reasonable thing and preserves the semantics of your quoted strings (as is promised by the documentation):

  $ echo "'foo'" | black -
  "foo"
  
  $ echo "'foo[\"bar\"]'" | black -
  'foo["bar"]'

  $ echo "'foo[\"bar\"]+\\'baz\\''" | black -
  "foo[\"bar\"]+'baz'"

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

#63

Post by ericvsmith »

cdrini wrote: post #58
ericvsmith wrote: post #40

Earlier quoted context omitted.

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.

There would be a __future__ import to turn it on, at least for some number of releases. But yeah, I'm not sure it should ever be the default behavior. It makes most sense to me as a per-module opt-in, but then a __future__ import doesn't make sense. And we've resisted having per-module pragmas, so maybe it's dead in the water.

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

#64

Post by ericvsmith »

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())

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

#66

Post by korethr »

Upon reading the title, I was not enthusiastic. Yet another way to format strings? What's wrong with String.format()? Get off my lawn!

However upon reading the article, it does feel more ergonomic to prepend your string literal with an 'f', and have it automagically reach out into the surrounding scope for the variables to format into the string.

I do worry a bit however about formatting not just expressions, but being able to call other code. Yes, that could be quite convenient for keeping the code concise and avoiding the kind of verbosity that confuses. However, I could also see someone forgetting to sanitize user-input data, and combined with the f-string, creating a remote arbitrary code-execution vulnerability. Sure, an attacker can't immediately start scribbling on memory in Python, there's more work he has to do first. But, he possibly could hijack the Python process to run whatever Python code he wanted.

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

#67

Post by ericvsmith »

korethr wrote: post #66

Upon reading the title, I was not enthusiastic. Yet another way to format strings? What's wrong with String.format()? Get off my lawn! However upon reading the article, it does feel more ergonomic to prepend your string literal with an 'f', and have it automagically reach out into the surrounding scope for the variables to format into the string. I do worry a bit however about formatting not just expressions, but bei…

Executing user-provided code isn't possible. f-strings must be literals, so there's no user-defined strings involved.

You could of course eval something the user provided, but there's no more of a risk with f-strings than there is with regular code.

This is addressed in PEP 498.

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

#68

Post by ericvsmith »

theptip wrote: post #52

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.

f-strings are so much faster that I've seen an increase in speed over %-formatting for logging. If there's even a 10% chance that a string will be actually logged (and therefore %-formatting will take place), I'll replace it with an f-string and not care about the deferred formatting.

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

#70

Post by stubish »

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 think rendering of the string can be lazy, deferred until actually needed.

Post reply on HN