[macNchz]

Well now we'll have four different ways to format strings, since removing old ones is something that doesn't actually happen:

    "foo %s" % "bar"
    "foo {}".format("bar")
    bar = "bar"; f"foo {bar}"
    bar = "bar"; t"foo {bar}" # has extra functionality!

[amenghra]

This is where an opinionated linter comes in handy. Ensures people gradually move to the “better” version while not breaking backwards compatibility.

It does suck for beginners who end up having to know about all variations until their usage drops off.

[QuercusMax]

The linter is a big deal, actually. I've worked with Python off and on during the past few decades; I just recently moved onto a project that uses Python with a bunch of linters and autoformatters enabled. I was used to writing my strings ('foo %s % bar), and the precommit linter told me to write f'foo %{bar}'. Easy enough!

[rtpg]

printf-style formatting ("foo %s" % "bar") feels the most ready to be retired (except insofar as it probably never will, because it's a nice shortcut).

The other ones at least are based on the same format string syntax.

"foo {}".format("bar") would be an obvious "just use f-string" case, except when the formatting happens far off. But in that case you could "just" use t-strings? Except in cases where you're (for example) reading a format string from a file. Remember, t- and f- strings are syntactic elements, so dynamism prevents usage of it!

So you have the following use cases:

- printf-style formatting: some C-style string formatting is needed

- .format: You can't use an f- string because of non-locality in data to format, and you can't use a t- string due to dynamism in

- f-string: you have the template and the data in the same spot lexicographically, and you just want string concatenation (very common!)

- t-string: you have the template and the data in the same spot lexicogrpahically, but want to use special logic to actually build up your resulting value (which might not even be a string!)

The last two additions being syntax makes it hard to use them to cover all use cases of the first two.

But in a specific use case? It's very likely that there is an exact best answer amongst these 4.

[milesrout]

.format is also nice because you can have more complex subexpressions broken over multiple lines instead of having complex expressions inside the {}.

[masklinn]

> printf-style formatting ("foo %s" % "bar") feels the most ready to be retired (except insofar as it probably never will, because it's a nice shortcut).

It’s also the only one which is anything near safe for being user provided.

[pansa2]

I don’t think I’ve ever used % formatting in Python - what makes it safer than `format`?

[masklinn]

`str.format` allows the format string to navigate through indexes, entries, and attributes. If the result of the formatting is echoed back and any non-trivial object it passed in, it allows for all sorts of introspection.

printf-style... does not support any of that. It can only format the objects passed in.

[rtpg]

Very good point. While I think we could do away with the syntactic shorthand, definitely would want to keep some function/method around with the capabilities.

[skeledrew]

And if it's being used, and isn't considered problematic, then it should remain. I've found use for all the current ones: (1) for text that naturally has curlies, (2) for templating (3) for immediate interpolation, and improved at-site readability

I see (4) being about the flexibility of (2) and readability of (3). Maybe it'll eventually grow to dominate one or both, but it's also fine if it doesn't. I don't see (1) going away at all since the curly collision still exists in (4).

[pletnes]

There is also the template module from the python 2 days.

[milesrout]

Don't forget string.Template:

    import string
    t = string.Template("foo $bar")
    t.substitute(bar="bar")

[darthrupert]

Five, if you count the log module. I hope t-strings will come there soon.

log.error("foo happend %s", reason)