The important thing for localization is to allow the strings to be swapped at runtime by loading them from some kind of database in a way where the arguments are at least numbered, if not named, so as to let them appear in different orders for different languages. The interpolation syntax does not seem, to me, allow for this: it is an "implicit" syntax offered during parsing to take a constant string and immediately build it out of parts, as opposed to the "explicit" % operator or .format methods: it is extremely clear with these two models how one would load a template that has the strings in a different order, or which used a different subset of the strings.

    >>> '%(one)s %(two)s'%{"one":"hello", "two":"world"}
    'hello world'
    >>> '{one} {two}'.format(one="hello", two="world")
    'hello world'

The PEP that is looking at this problem has been deferred: at the end of the document they kind of indicate that they didn't really think about the i18n problem correctly and so don't actually have a good solution to present, and are going back to think about it more.

https://www.python.org/dev/peps/pep-0501/.

If you need to localize, you still have format(). You just happend to have a shorthand to do it for the 80% case, just like you have @decorator as a shortcut for decorated = decorator(decorated) or [x for x in z] as a classic loop alternative.

Yes, having so many solutions is not ideal, espacially when it comes to teach the language. However, it would be foolish to avoid improving the usability of Python just to avoir having "one more way to do it".

I do wish they'd deprecate Template though. It's more than useless.

string.Template is the one used for i18n, it is simple for the end user so has a use.

I suppose they need to add an API so that f-strings can be automatically presented to gettext or another translation database layer before substitution is performed.