If I were creating a new language today there is absolutely no question in my mind: I would have the default string type support interpolation. It means that th

If I were creating a new language today there is absolutely no question in my mind: I would have the default string type support interpolation. It means that there is a particular character or character combination ("{" for python, "${" for JavaScript, etc) which is not allowed in strings without escaping -- that isn't much of a usability problem: we live with the need to escape new lines in strings and no one even thinks twice. But changing it in an existing language causes massive backward compatibility issues. Unlike the move from Python 2 to Python 3, it is trivial to build a perfect migration script (2to3 was useful but not perfect) -- it just needs to prefix "p" in front of all normal strings, or at least in front of all normal strings that contain the interpolation character(s). But even so, the need to run that script is a VERY BIG DEAL. A perfect migration script doesn't help with sample code that is printed in a book, or thousands of other situations that are awkward to fix. It would, without a doubt, require very careful introduction by use of "from __future__ import". (The fact that Python has that facility is extremely helpful for this kind of migration.) I am utterly bewildered by this article's claim that the proponent of this change thinks it should be dropped if it is to be introduced carefully using "from __future__ import". That is just stupid. I would rather end up in a place where interpolation strings are the default, but it is not clear to me whether the path to get there is worth the pain.