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

121–130 of 147 posts

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

#121

Post by roelschroeven »

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've put together a proposal to have all strings be f-strings by default.

Please don't do that. Seriously.

There is this trend in the Python community of blurring the line between a plain string and a formatting operation on that string, but there is a fundamental difference between the two. Instead of trying to ignore that difference, the language should make the difference explicit. "Explicit is better than implicit" is one of the things I like so much about Python. Please don't throw that away.

There is and should be a clear and fundamental difference between a plain string and a string formatting operation. The plain string is clearly the more fundamental of the two, so it should be the default.

And then there's the whole issue of breaking code with such a change.

Again, please don't do it. Don't change the language in such a fundamental way.

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

#122

Post by wodenokoto »

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…

If I apply a bunch of functions to a variable before printing I tend to use .format() and do it inside the format call, e.g “{}”.format(a.lower().upper())

Something just feels more right about that. Maybe it is the code highlighting that works better.

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

#123

Post by akvadrako »

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.

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

#124

Post by [deleted] »

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…

[deleted]

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

#125

Post by angus_gh »

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…

The reason you get warned for doing

`logger.debug("Got %s results", num)`

instead of

`logger.debug("Got {} results".format(num))`

is that in the first case, internally it checks if the logger is disabled and if so skips formatting the string, whereas in the second case you've already formatted it before passing it in, so that work can't be avoided. This isn't the case for print statements because they don't execute conditionally, so you don't ever skip doing the format.

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

#126

Post by GlitchMr »

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.

Won't happen. This would be a breaking change that would break pretty much every usage of `str.format`. Releasing a new incompatible version of a language is unlikely considering Python 2 to Python 3 migration mess.

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

#127

Post by [deleted] »

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.

[deleted]

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

#128

Post by mbeex »

zo1 wrote: post #117
pfranz wrote: post #104

Earlier quoted context omitted.

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.

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

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

#129

Post by pbsds »

half-kh-hacker wrote: post #100
drdaeman wrote: post #89

The issue with f-strings is that they can't be used for i18n. AFAIK, it is impossible to make `_(f"Hello, {name}")` work - at least without a preprocessor or very arcane bytecode manipulation magic. This is unlike much uglier but common and well-supported `_("Hello, %(name)s") % {"name": name}`. In the examples I've used `_` as an alias for a `gettext` call - I believe this is a common practice to do something like `…

Not f-strings, but I am partial to something like: _("Hello, {name}").format(name=name)

    _("Hello, {name}).format(**vars())

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

#130

Post by earthboundkid »

pansa2 wrote: post #90
earthboundkid wrote: post #75

Earlier quoted context omitted.

Yes. Python in general has gone from being “executable pseudo code” to a series of complex language design trade offs largely because it had failed to grasp the right abstractions in its evolution. Backtick functions in JS are so powerfully clever and basically impossible to recreate in Python.

> Python in general has gone from being “executable pseudo code” to a series of complex language design trade offs Agree with this 100%. > because it had failed to grasp the right abstractions in its evolution. I'd be interested to know what you think the language's designers should have done differently?

Let’s go all the way back to `with`. What does it do? It encapsulates try/finally blocks and only try/finally. That is a weirdly specific thing to encapsulate. Why did they do that? Well, it turns out that making an anonymous block syntax that is compatible with Python’s grammar is hard, so you can’t have the equivalent of this JavaScript:

    WithOpen(filename, f => {
        // block
    })
Because blocks aren’t viable, problems have to be solved on a case-by-case basis, which is hard to do well and leaves gaps.
Post reply on HN