Despite being so cool, it's also a very under utilized feature, as it inherits all the formatting capabilities of format().

With format(), and hence with f-string you can:

# Replace datetime.stftime()

>>> f"{datetime.now():%m/%d/%y}"

'05/15/19'

# Show numbers in another base

>>> f"{878:b}"

'1101101110'

>>> f"{878:x}"

'36e'

>>> f"{878:e}"

'8.780000e+02'

>>> f"{878:o}"

'1556'

# Control the display of padding, filling, and precision of numbers

>>> 1 / 3

0.3333333333333333

>>> f"{1 / 3:.2f}"

'0.33'

>>> f"{69:4d}"

' 69'

>>> f"{69:=+8d}" '+ 69'

>>> f"{69:0=8d}"

'00000069'

# Center text

>>> f"{'foo':^10}"

' foo '

And so many other things, since you can create your custom __format__.

Not affiliated, but in this regard, I quite love https://pyformat.info/ as a format cheat sheet.

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

They just added a brand new feature in 3.8 that let's you just append = at the end for quick debugging:

>>> f'{5+5=}'

'5+5=10'

>>> foo = 5

>>> f'{foo=}'

'foo=5'

https://docs.python.org/dev/whatsnew/3.8.html#f-strings-now-...

This just feels like another example of Python slowly creeping more esoteric syntax into the language, making it harder for beginners to approach the language.

Beginners don't have to know or touch any of this though. They can keep using normal strings until at some point they learn about f strings and see a need for them. You don't need to stop adding features to a language just because a beginner won't be able to learn everything. They don't need to.

I think the point is, a beginner coming across some code using such esoteric features is going to be a bit lost as to what's going on. With most of Python you can see what it's doing even if you didn't know the syntax before. That's true of basic f-strings, but not so much with some of this stuff.

Yeah languages are meant to be read even by beginners. I think a language like python shines by being small (in design) yet powerful (by capability). Having myriads of "nice for one use case" feature in the language is not the way forward. I long for the time where % format and .format are removed from the language spec. Even if they still work on the implementation for compatibility. Please remove things.

> Please remove things.

We're not done with Python 2 yet. This would be a Python 4 for sure. That's not according the philosophy of backward compatibility of Python (even if I agree with you).

Yes backward compatibility is not an option (lets avoid redoing python3 trauma ) and simply delegating coexistence of old and new features to implementation is a bit lazy. However documenting one way as the current one and other features as old ways, for backward compatibility can simplify things.

As someone who probably relies on print statements too much for debugging, I love this.

I don't get it. Why not just write:

>>> f'{foo}=' 'foo=5'

there's a pattern in debugging that basically looks like

   print('foo=',foo)

like all languages should, if a pattern is wide-spread, useful and basically boilerplate, python decided to create a language shortcut for it.

   print('f{foo=}')

f before the quote though

doh! classic 'your bick is dig', can't even edit now :(

I had a co-worker who like the convention:

  >>> 'User {user} has logged in and did an action {action}.'.format(**locals())
  'User Jane Doe has logged in and did an action buy.'

I thought it was clever at first, but noticed it was frustrating to refactor because it was hard to see the scope of variables (especially if the template string is defined elsewhere). I don't lean heavily on IDEs, but at the time it would flag many required variables as unused because it couldn't grok this.

Do you find the same problems when using f strings?

    >>> 'User {user} has logged in and did an action {action}.'.format(**locals())

D:

To me, this is pretty gross. This implicitly requires all the correct variables to be bound in the local scope, and there's no easy way to check that this is the case without reading all of the code leading up to this point (which is bad, in my opinion). Because what this really does is create string-level variables `user` and `action` and pass the values of similarly-named (i.e., shadowed) variables in the outer (but still local) scope in their place. This is why IDEs struggle with this: they can't simply know the contents of the dictionary returned by the function `locals()` without actually executing the code (unless they special-case calls to functions named `locals`, but this causes problems if the user ever shadows this name).

F-strings directly use the bound variables in the outer (but still local) scope:

    >>> f'User {user} has logged in and did an action {action}.'
    'User Jane Done has logged in and did an action buy.'

This avoids the shadowing problem, thus making it easy to use with IDEs and (IMO) easier to grok while reading directly, although maybe most people don't think about shadowing to the same extent I do and wouldn't be as bothered by this in general. Still, the IDE support is incredibly useful.

> Do you find the same problems when using f strings?

No, you can't define f strings elsewhere, and in theory your IDE can statically analyze them just as the Python interpreter does. In practice, your IDE might suck, I don't know.

there are python implementations where locals() is unavailable or available at significant cost.

Before I knew about F strings my .formats() were just so long. F strings are nice for sure

Conda with pipenv = great

it's great if using debian where it's still on 3.5. installing miniconda lets you have the newest python easy-peasy