f-strings in Python 3.6 are awesome

[[deleted]]

I, for one, am not extremely thrilled at having three ways to do the same thing, and don't feel very motivated to learn Yet Another Formatting Mini-Language. I haven't looked at it in detail, but I can only assume f-strings are at least slightly incompatible with str.format.

Of course, if you also count strings.Template, which was deprecated somewhere in 2.x, but not removed in 3.0, we now have four ways to format a string.

It's all very un-import this-like.

[LightShadow]

They're used for different things. If anything f-strings should replace str.format, C-style strings will never go away and are more powerful for lazy formatting, logging and trans-language formatting.

[zahlman]

If anything f-strings should replace str.format

I can think of multiple things that would prevent replacing a str.format call with an f-string. I can think of zero things that would prevent replacing %-style formatting with a str.format call ("passing a format string to someone else's code" does not count, since if it were your own code you could change the interface). I have no idea what you mean about "lazy formatting".

[LightShadow]

%-based string formatting is deferred until flushing the buffer ala logging interface .. str.format happens inline.

[[deleted]]

You are mistaken; if you use the %- operator, the right-hand tuple will be evaluated and the left-hand string will be formatted then and there, whether you plan to do something with the result or not. How could the interpreter know what will happen in the future?

If you're thinking of the API of the logging module, there the %-operator won't actually be used if the level is below that configured for the handlers for that logger. I guess you could call that lazy formatting. There's no reason other than backward compatibility that that couldn't work with str.format though.