What's more, it's being hailed at a plus for localization which it isn't. Localizers should never, ever deal with string interpolation - anything past what .format() does is essentially untranslatable.
I am not sure why i18n is a big deal, let another library deal with it.
Whatever, I have the choice not using this feature after it is accepted and implemented. Their PEP discussion on email always ended up in tangential. Problem I always have with string manipulation is dealing with long string, which for coding style I'd split into multiple +, and thus using format is pretty ugly.
Is it really worth updating all the Python syntax formatting and analysis code out there just to save one character on an operator? I don't think it's a good tradeoff.
That's because some languages have complicated changes in the text depending on eg the number of things: not just singular/plural, but more complicated. Russian is one example.
It also has little in common with i18n, the use cases differ too much. Perhaps in the future someone can figure out how to bring them together, but not today.
"{a} {b} {a}".format(a=a, b=b)
"{a} {b} {a}".format(**locals())
Compared to this: f"{a} {b} {a}"
Sorry that's about 1000% better. This should have been the one way to do it, originally. It isn't magic either, rather a simple compile-time transformation to existing format syntax. There's nothing new to remember besides a large reduction in noise. fmt("{a} {b} {c}", a=a, b=b, c=c)
If you want to save typing, maybe use :a instead of {a}. Or ?a would have made plain old ? a nice positional variant: fmt("?a ? ?", a=a, b, c)
The main benefit of the fmt function is that it requires no syntax changes to the language and is trivially provided by a third party library for all past versions of Python.That being said this ship has sailed. I guess I just take a more conservative approach to syntax changes than most.
Update: a bit sad to see my votes fluctuating wildly on this post. Please don't use votes to support or disagree with me: that's not what they're for. Please vote only based on whether you find this relevant.
with open('template.txt') as f:
template = f.read()
formatted = template.format(**values) _(f"English {a} words {b} here {a}")
The interpolation is done before the string is passed to gettext which can't retrieve the translated string any more. "{} {}".format(a, b)
"%s %s" % (a, b,)
That's not very convincing. I was hoping this article would make a good case for interpolated strings, since it's starting to feel like Python is having an identity crisis. Type annotations especially took me by surprise, but string interpolation is another good example of an addition that doesn't feel like Python (imho, anyway). >>> very_long_var_name_1 = 'spam'
>>> very_long_var_name_2 = 'ham'
compare >>> # Explicit but tedious and doesn't help readability:
>>> print('{very_long_var_name_1}: {very_long_var_name_2}'.format(
... very_long_var_name_1=very_long_var_name_1,
... very_long_var_name_2=very_long_var_name_2))
spam: ham
with >>> # Explicit but somehow feels dirty:
>>> print('{very_long_var_name_1}: {very_long_var_name_2}'.format(
... **locals()))
spam: ham
and >>> # Still fits on one line. I think f prefix makes intent clear.
>>> print(f'{very_long_var_name_1}: {very_long_var_name_2}')
spam: ham"There should be one-- and preferably only one --obvious way to do it."
There are a lot of warts on that snake, but I still really like using Python.
#python
import re
m = re.search('(a.+)(d.+)', 'abcdef')
if m:
print(f"{m.group(1)},{m.group(2)}")
#perl
if('abcdef' =~ /(a.+)(d.+)/){
print "$1,$2";
}Also "Simple is better than complex", "practicality beats purity" and "Readability counts".
The zen is not the bible, you don't get to cherrypick the stuff you want to make your case.
Plus, they are just guide lines, in the end, you have a debate in the python dev mailing list with reasonable people making their case.
"%s %s %s" % (a, b, a)
"{} {} {}".format(a, b, a)
If you want placeholders to match variable names, you can do: "{a} {b} {a}".format(a=a, b=b)
"{a} {b} {a}".format(**locals())
So this is just unnecessary (especially since the "f" prefix is easier to miss than a "format" method): f"{a} {b} {a}"
And this is downright obfuscated—putting operators inside of string literals: f"{a + ' ' + b + ' ' + a}"https://www.python.org/dev/peps/pep-0498/#no-use-of-globals-...
You could argue that's not a good enough reason, but it's there.
You've all been programming in C-like languages for far too long to realize what a horrible design string formatting is. You can argue over "explicitness" all you want, the new way is easier to learn, easier to read, makes more intuitive sense, requires learning fewer rules, ad is close enough to the format string method that they work well together.
The one counter argument that makes sense to me is that in general we shouldn't be doing easy string interpolation, since that way lies SQL injection, XSS, etc, and should instead rely on a stronger type system with binary text blobs, HtmlStrings, SqlStrings, etc, with automatic escaping into and out of the data type.
But then that's not the case with Python now. If you're only trying to stick this string inside that string in a quick and dirty manner, I totally don't understand the reticence folks have to something the way ruby does it: "Name: #{first_name}".
Don't get me wrong, I'd like Python to have better, more obvious, more concise string formatting. However the last time we had this discussion, it was about str.format() and how it was going to be awesome and don't worry modulo-formatting will go away.
Turns out it did not; modulo formatting is still there because why would it be removed. This is history repeating itself - are you actually baffled that some people learn from past mistakes?
It may be true that
"{} {}".format(a, b)
is a bit verbose, but it is crystal clear and clean. Just remember the Python Zen: "There should be one-- and preferably only one --obvious way to do it." _and_ "Explicit is better than implicit."from __future__ import string_interpolation
:)
...Or just do it in 28 lines of Lua:
http://hisham.hm/2016/01/04/string-interpolation-in-lua/
This is a nice showcase of how Lua's metamechanisms can be applied to do things that often require new features in other languages.
Now if python would begin to support immutable values by default then I'd be most content, and Python complete enough.
Hoping for a decision from the core team – having both f"" and .format is a pretty clear deviation from this principle.
If Python 3.6 is going to introduce multiple ways to do the same thing, there is no good reason to not merge Python 2 and 3 together and have both set of behavior co-exist with each other (__future__ or __past__).
In one shot, you break the Berlin wall of Python.
P3 '.format 'is fine, the only problem I have is forgetting the last ')' and vim picks this up. Is interpolation that good to introduce another way of doing things?
So funny ... the most prominent language known for this stuff is PHP ... and missing :D