Readability absolutely counts - that's precisely the reason why the "one obvious way" rule is there.
If there's four different ways to something, then that's four different things the reader has to fully understand in order to parse someone else's code.
> If there's four different ways to something, then that's four different things the reader has to fully understand in order to parse someone else's code.
Sure, which is why .format() kind of sucks.
> "Hi {name}, your age is {age}".format(name=name, age=age)
You have to parse 'name' and 'age' three times to figure out whats going on. The .format() is completely superfluous in most cases. It's busywork and it's harder to parse.
I quite agree with the "one obvious way" to do something, but that should not hinder progress and improvement. f strings are an improvement and are the obvious way to do things, in the same way that '.format' was an improvement over 'str % values', and how 'str % values' is an improvement over manual concatenation.
They all still exist, but lets use f strings now and stop complaining?
I'm sorry, but I think you missed my point here. There's now four different ways to do string interpolation, which means that to understand someone else's code, I will need to know how `%`, `.format`, `string.template` and `f` works - I won't know which method the library author uses. I will need to know how they break in edge cases (and they will be broken, otherwise we wouldn't have replaced them!)
Worse still, I will also need to know how they interact with each other - you can do
something = "abc"
x = f"{something}".format(something="def")
and I honestly have no idea what x will be.
So yeah, I would love to "use f strings and stop complaining", but the fact that the other string interpolation methods still exist, and are still supported, is still going to be a problem.
It's not obvious which .format() is evaluated first, though. For 'in-line' string interpolation I think the f'' syntax wins. .format() is still nice for template-style interpolation though. For this reason, and to avoid situations like the parent, I think it should be made static, so that you could write:
If there's four different ways to something, then that's four different things the reader has to fully understand in order to parse someone else's code.