String concatenation without '+' operator

Question

I was playing with python and I realized we don't need to use '+' operator to concatenate strings unless it is used directly.

For example:

string1 = 'Hello'   'World'  #1 works fine
string2 = 'Hello' + 'World'  #2 also works fine

string3 = 'Hello'
string4 = 'World'
string5 = string3   string4  #3 causes syntax error
string6 = string3 + string4  #4 works fine

Now I have two questions:

1. Why statement 3 does not work while statement 1 does?
2. Is there any technical difference such as calculation speed etc. between statement 1 and 2?

Answer 1

From the docs:

Multiple adjacent string literals (delimited by whitespace), possibly using different quoting conventions, are allowed, and their meaning is the same as their concatenation. Thus, "hello" 'world' is equivalent to "helloworld".

---

Statement 3 doesn't work because:

The ‘+’ operator must be used to concatenate string expressions at run time.

Notice that the title of the subheader in the docs is "string literal concatenation" too. This only works for string literals, not other objects.

---

There's probably no difference. If there is, it's probably extremely tiny and nothing that anyone should worry about.

---

Also, understand that there can be dangers to this:

>>> def foo(bar, baz=None):
...     return bar
... 
>>> foo("bob"
... "bill")
'bobbill'

This is a perfect example of where Errors should never pass silently. What if I wanted "bill" to be the argument baz? I have forgotton a comma, but no error is raised. Instead, concatenation has taken place.

Answer 2

This is implicit string literal concatenation. It only happens with string literals, not variables or other expressions that evaluate to strings. There used to be a (tiny) performance difference, but these days, the peephole optimizer should render the forms essentially equivalent.

Answer 3

Why statement 3 does not work while statement 1 does?

Because, in the first statement, we are assigning some constant to a variable. Variable assignment is simple enough such that we can keep on putting multiple constants to a single variable and the assignment will still go through. The terms "hello" and "world" are two constants of same type. So, the statement worked.

If we do the following, we will get SyntaxError

string1 = "Hello" 1

The reason is that we supplied multiple constants in a single variable assignment. This confused python and it thrown it out as an error.

The statement 3 is all about assigning a variable based on two variables. This will produce SyntaxError as python don't know what it can do with 2 variables before assigning it to the variable.

Is there any technical difference such as calculation speed etc. between statement 1 and 2?

Yes. The only technical difference is readability rather than anything else. Readability matters most in Python. For an untrained eye, "hello" "world" might look like the compiler would add the space to the strings. Which is not the case.

However,

"hello" + "world"

is explicit and normal. Nearly always, Explicit is better than implicit.

Answer 4

You can use %s as this is more efficient than using + sign.

>>> string2 = "%s %s" %('Hello', 'World')
>>> string2
'Hello World'

(OR)

---

one more method is .format

>>> string2 = "{0} {1}".format("Hello", "World")
>>> string2
'Hello World'
>>> 

Answer 5

To answer your second question: There is no difference at all (at least with the implementation I use). Disassembling both statements, they are rendered as LOAD_CONST STORE_FAST. They are equivalent.

Answer 6

Statement 3 doesn't work as when you concatenate two string expressions to create a new string you need a '+' operator.

whereas in case of sting 1,2 and 4, adjacent literals separated by white spaces use different quoting conventions.Hence they are allowed making them print same as their concatenation.

also, there won't be any significant or noticeable time difference in running those 2 operations.

%%timeit -n 1
s1='ab'
s2='ba'
print(s1+s2)

o/p The slowest run took 17.08 times longer than the fastest. This could mean that an intermediate result is being cached. 57.8 µs ± 92.5 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)

%%timeit -n 1
s3='ab' 'ba'
print(s3)

o/p The slowest run took 4.86 times longer than the fastest. This could mean that an intermediate result is being cached. 25.7 µs ± 21 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)