Logging modules mostly, especially if you have objects that can take a while to serialize to a string, can benefit from the "old" format string approaches. (Percent formatting is for some reason favored, although there's no real good reason to not just use the .format() approach outside of the standard logging library being a dinosaur.)

For conditional formatting (where you don't know if the formatting is needed or the contents of what you're formatting into the string but you know what you want to format), f-strings also lose their use pretty much immediately.

They're great for a quick inline format but less useful for things like string templates you want to use over and over.

Be sude that would make it hell to write strings with literal {}.

I like having different types of strings with different sets of magic characters. Even having identical `'` and `"` strings just to avoid backslashes in a few cases is great.

From the start? I guess because the spirit of Python's syntax is anti-Perl.

Now? Maybe because another breaking change in strings is the worst nightmare of the current generation of Python developers.

Python f-strings are modelled after `string.format`, which is inspired by C# and introduced relatively later. Such interpolated strings would have been much more inconvenient for the older printf-like syntax.

Yea, Swift really shows how it should be done. One string literal type that can do everything f-strings, r-strings, and """-strings can do and much more.

> Never really understood why not all strings were f-strings in python.

Sometimes you don't want interpolation, and it seems more reasonable to default to a version without such a feature than to default to a version with it and have an alternate syntax for non-interpolated strings. Or, at least, that makes sense to me, but I have no knowledge of their motivations.

Because it wouldn't be backwards-compatible.

If Python were designed from scratch today, I suspect it'd do something similar to JS.