> I quite love https://pyformat.info/ as a format cheat sheet.

I never knew this existed but that's awesome! Thanks for the link!

To this novice, the "Old" way looks so much better.

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.

I love F-strings, my only gripe is the chosen syntax for invoking them. For starters, F may or may not be capitalized, so these two lines are identical.

  F"My string with {interpolated_value}"
  f'My string with {interpolated_value}'

Like using apostrophes or quotation marks to enclose strings (or F-strings), I find myself wasting time questioning the trivial notion of whether to capitalize or not.

I think Groovy's syntax is great, where quotation marks denote an interpolated string, and apostrophes denote a plain old string.

  "This is my ${interpolated_value} string"
  'This is my plain old string'

But these are nitpicks, and it's really too late to implement something like that.

> I think Groovy's syntax is great, where quotation marks denote an interpolated string, and apostrophes denote a plain old string.

That's Perl's syntax, from about 15 years before Groovy, whippersnapper. Off my lawn, now.

Yeah, Groovy got it from Ruby which got it from Perl.

Yeah, Ruby uses the doublequote/singlequote distinction from Perl, but Ruby tags variables to interpolate with #{}, while Groovy and Perl use $.

Oh, although I guess Perl got that syntax from the Bourne shell…

> Yeah, Ruby uses the doublequote/singlequote distinction from Perl, but Ruby tags variables to interpolate with #{}, while Groovy and Perl use $.

Huh, I could have sworn that I remembered that Groovy has taken it from Ruby.

Incidentally, Ruby uses just # for variables, it uses #{} for arbitrary expressions. A common style prefers #{} even where # alone works, though.

#notallvariables

Apache Groovy's string syntax is deficient, not great. It doesn't have the docstrings syntax that Python, Ruby, and Perl all use.

An early beta version of Groovy 1.0 had it (thanks to a Sam Pullara), but it was later yanked out. Groovy's self-styled Project Manager at the time said he only wanted syntax in Groovy that would cause the Java syntax highlight rules in Eclipse and Netbeans to highlight Groovy code similar to Java, so if a manager was walking around the programming area, the screens would look like the programmers were using Java.

And that's how Groovy got its deficient string syntax.

What old way ? %, zfill, strftime, or some hack with len() ? Having a unified syntax with all formatting needs is a big deal.

I agree, it seems to be getting away from "explicit over implicit".