I believe that, when most people say "string interpolation", they mean "first class string interpolation syntax", as opposed to the use of function invocation. I don't have citations, but I hope this perspective helps in some way.

printf-style specifiers and substitutions, like in the examples GP provided, aren't considered string interpolation.

> "My name is {name} and I am {age} years old".format(name=name, age=age)

This is a textbook example of string interpolation.

You can look it up on wikipedia. I am not sure what you mean.

The wikipedia examples are somewhat misleading.

The string "My name is {name} and I am {age} years old" is a plain string. By itself, there is no interpolation:

    >>> x = "My name is {name} and I am {age} years old"
    >>> x
    'My name is {name} and I am {age} years old'

The format function is what confers meaning. This is identical to a standard printf situation, wherein the string "%d %x" encodes a transformation but in and of itself isn't a transformation.

Contrast with the proposal for f-strings:

    >>> x = f"My name is {name} and I am {age} years old"
    # this is an error unless name and age are defined

The literal mandates a particular interpretation, and the f-string cannot exist outside of that in the same way that the standard string does. Or as the PEP puts it:

> It should be noted that an f-string is really an expression evaluated at run time, not a constant value.

By itself there's no interpolation, which simply means it's not an expression.

But when you do: "{foo} {bar}" % {"foo": "blah", "bar": "blooh"}, this is string interpolation.

Is there a definition, anywhere(even a book would suffice), where it has your strict definition of what interpolation is?

I'm not trying to undermine the usefulness of the interpolated expressions and what you said. I just really want to know if the definition is so strict.

UPDATE: http://rosettacode.org/wiki/String_interpolation_(included)

I think that you are the one who's making the definition so specific and strict. I can't find a single source on the Internet that agrees with your definition.

Reading the text of the Wikipedia article, I think it does make a distinction between the two styles.

  string interpolation is the process of evaluating a string literal containing
  one or more placeholders, yielding a result in which the placeholders are 
  replaced with their corresponding values.

I read this as saying that the evaluation of the string literal yields a string where the substitution has already been made. That's not the case with the format style of "string interpolation." You provide a template string and call a function with some arguments, and that replaces the placeholders. The string literal does not handle the substitutions itself. I believe the Wikipedia article agrees that this is the deciding factor.

A few sentences later, the article includes this statement:

  Some languages do not offer string interpolation, instead offering a standard
  function where one parameter is the printf format string, and other(s) provide
  the values for each placeholder.

This sounds pretty similar to what was in Python prior to this release (especially if you know how methods work in Python).

Also notice how the statement begins by saying that not all languages offer string interpolation. I think that's the final nail in the coffin of the argument. You could use virtually any language to write a function that handles substitutions in template strings. If that qualified as string interpolation then every language would have it. Since some languages do not, I think we can safely say that we're talking about a syntax feature.

Dont worry :) soon the other ways will be deprecated. There can be only one _pythonic_ way to do it.

I remember when I started python that one of the big differences was that there wasn't a 1000 ways to do something, but one right way.

There's always been multiple ways to do something in Python, just one best way, and the best way has been known to change between versions.

See: list comprehensions obsoleting most uses of map() and filter(), then generator expressions obsoleting any uses of list comprehensions that don't need a list object

Here's four ways to do the same thing.

Naïve way:

    foo = []
    for x in bar:
        if meets_some_condition(x):
            foo.append(transform(x))
    do_something_with(foo)

With map/filter:

    do_something_with(map(transform, filter(meets_some_condition, bar)))

With list comprehensions:

    do_something_with([transform(x) for x in bar if meets_some_condition(x)])

With generator expressions:

    do_something_with(transform(x) for x in bar if meets_some_condition(x))

All four of those are valid in modern Python, but the latter and only the latter is the right way to do it.

Before Python 2.0, either map/filter or the naïve way was the right way (TBH, I'm not familiar with what was considered right in the old days). When Python 2.0 came out, list comprehensions became the right way. When Python 2.4 came out, generator expressions became the right way. The right way depends on your version of Python.

Or for that matter, look at old-style classes vs. new-style classes. When new-style classes came out, they immediately became the one and only right way to do classes, but old style classes still stuck around for the rest of the 2.x series.

I'm going to disagree with you there and prefer the "naive way". This is the clear and explicit way to express your intent. Personally, I'm a big fan of a few more lines for more clarity (within reason), and not a fan of unique, language-specific incantations like comprehensions just for the sake of syntactic sugar.

An implicit coding style that requires the reader to look up the semantics of Python's comprehensions (and also makes it harder to unwind/inject debugging/keep line lengths reasonable) is a negative unless you're gaining something besides brevity.

I understand some claim that comprehensions are faster for various reasons, but this is presumably implementation dependent and shouldn't be assumed unless you know it's the case in your implementation. I also understand that the generator expression uses less memory, but the generator version can be written the long way too:

    def test_bar(bar):
        for foo in bar:
            if meets_some_condition(foo):
                yield transform(foo)

    do_something_with(test_bar(bar))

I know that Python is pretty reasonable but I don't like starting the descent down into the alphabet-soup madness that we get in a lot of other languages.

But List comprehensions, and now generators, are what python, "Pythonic". I'm a relative novice with python, but they are straightforward to understand, and are fairly consistently used by practitioners of the language.

But, I agree with you regarding creeping complexity in general - @wrappers/decorators confused me for the longest time, and I often wonder how someone not familiar with the language is supposed to understand what they are doing.

> This is the clear and explicit way to express your intent.

I disagree. For the (common) circumstances where genexp's are appropriate, they are also the most clear and explicit way of expressing intent (explicit loops express the mechanism, not the intent.)

For cases where you need a list object, list comprehension are the most direct expression of intent.

There's cases where explicit looping is the most clear expression of intent; usually, this would be where complex logic is needed within each loop iteration.

To be fair, string interpolation is an outlier. Also, Python 3 cleaned up a few areas where there were redundant ways to do something, like standard library modules that had both C and (pure) Python versions.

Yup, we could do with a python4 to clean things up ...