Comment by qquark | Hacker News Reader

Comment by qquark | Hacker News Reader

Parent Full thread

This is maybe not directly visible in the parent comment, and particularly not on the website, that is compatible with old versions of python also, but to me there's a huge difference in usability also in the ability to use variable names in the current scope without additional verbose crap by default. This seems secondary to a lot of people, but to me that changes everything:

  >>> x = 1
  >>> f"{x}"
  '1'

This is much more readable than:

  >>> "{x}".format(x=x)
  '1'

  >>> "{}".format(x)
  '1'

It makes the code immensely more readable than having to count parameters, especially for long strings with a lot of data in them. Counting is for computers, not programmers; I shouldn't have to count anything for such a trivial task.

So, thanks to f"", no need for what I find to be an ugly additional call to .format(...), that is just visual clutter for most cases.

The only reasons I could see for a call with a dedicated dict is data exfiltration from a user provided format string executed on python code they do not control, or renaming/subsetting of keywords for cleanliness. Both are special cases, and that's the effect the current implementation has, thankfully.

I see your point, but the syntax inside of fstrings forms an entirely new sub-language (DSL). I can look at old python and know exactly how the .format() calls parse with positional and named keyword arguments, but looking at the fstrings I need to be familiar with all of the new magic.

I've heard similar complaints about the loop macro in Common Lisp, and this feels a bit like shell or Tcl strings which could mean anything (arguments to sed/awk or paths to widgets/urls). However, I guess people are familiar with regular expressions as a completely foreign nested language (DSL), so this isn't much different than that.

I disagree, especially when using named parameters. The new style is too implicit.

How is it implicit? Every insertion is expressed in exactly the place where it will print. It's way more explicit than having a placeholder and a value on completely different parts of the expression.

> It's way more explicit than having a placeholder and a value on completely different parts of the expression.

No its not.

  "My name is {}, I'm {}'{}'' tall and live in {}".format(name, location, feet, inches)

This error is much better hidden than in the equivalent:

  f"My name is {name}, I'm {location}'{feet}'' tall and live in {inches}."

I did mention named parameters, you are using positional parameters to make your point. You don't even list the variables in your example. That seems pretty implicit to me.

I think this is more explicit:

"My name is {name}, I'm {feet} tall and live in {location}.".format(name="Bob", location="USA", feet=7)

Your example is not representative because you're using literals.

Your actual example would be:

    "My name is {name}, I'm {feet} tall and live in {location}.".format(name=name, location=location, feet=feet)

And with f-strings:

    f"My name is {name}, I'm {feet} tall and live in {location}."

f-strings is clearly more readable, concise and actually faster to run.

The literals were just an example. And personally I find it more explicit, which is my original point.

If its faster to run, then fair enough.

Using your example, I think

"My name is {name}, I'm {feet} tall and live in {location}.".format(name="Bob", location="USA", feet=7)

is less explicit than

"My name is Bob, I'm 7 feet tall and live in USA."

and that last one is faster to run ;-)

Yes it is.

Reply on news.ycombinator.com