[qquark]

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.

[civility]

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.

[collyw]

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

[hannasanarion]

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.

[collyw]

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

No its not.

[majewsky]

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

[collyw]

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)

[isaacremuant]

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.