Why does b+=(4,) work and b = b + (4,) doesn't work when b is a list?

If we take b = [1,2,3] and if we try doing: b+=(4,)

It returns b = [1,2,3,4], but if we try doing b = b + (4,) it doesn't work.

b = [1,2,3]
b+=(4,) # Prints out b = [1,2,3,4]
b = b + (4,) # Gives an error saying you can't add tuples and lists

I expected b+=(4,) to fail as you can't add a list and a tuple, but it worked. So I tried b = b + (4,) expecting to get the same result, but it didn't work.

The problem with "why" questions is that usually they can mean multiple different things. I will try to answer each one I think you might have in mind.

"Why is it possible for it to work differently?" which is answered by e.g. this. Basically, += tries to use different methods of the object: __iadd__ (which is only checked on the left-hand side), vs __add__ and __radd__ ("reverse add", checked on the right-hand side if the left-hand side doesn't have __add__) for +.

"What exactly does each version do?" In short, the list.__iadd__ method does the same thing as list.extend (but because of the language design, there is still an assignment back).

This also means for example that

>>> a = [1,2,3]
>>> b = a
>>> a += [4] # uses the .extend logic, so it is still the same object
>>> b # therefore a and b are still the same list, and b has the `4` added
[1, 2, 3, 4]
>>> b = b + [5] # makes a new list and assigns back to b
>>> a # so now a is a separate list and does not have the `5`
[1, 2, 3, 4]

+, of course, creates a new object, but explicitly requires another list instead of trying to pull elements out of a different sequence.

"Why is it useful for += to do this? It's more efficient; the extend method doesn't have to create a new object. Of course, this has some surprising effects sometimes (like above), and generally Python is not really about efficiency, but these decisions were made a long time ago.

"What is the reason not to allow adding lists and tuples with +?" See here (thanks, @splash58); one idea is that (tuple + list) should produce the same type as (list + tuple), and it's not clear which type the result should be. += doesn't have this problem, because a += b obviously should not change the type of a.

They are not equivalent:

b += (4,)

is shorthand for:

b.extend((4,))

while + concatenates lists, so by:

b = b + (4,)

you're trying to concatenate a tuple to a list

When you do this:

b += (4,)

is converted to this:

b.__iadd__((4,)) 

Under the hood it calls b.extend((4,)), extend accepts an iterator and this why this also work:

b = [1,2,3]
b += range(2)  # prints [1, 2, 3, 0, 1]

but when you do this:

b = b + (4,)

is converted to this:

b = b.__add__((4,)) 

accept only list object.

From the official docs, for mutable sequence types both:

s += t
s.extend(t)

are defined as:

extends s with the contents of t

Which is different than being defined as:

s = s + t    # not equivalent in Python!

This also means any sequence type will work for t, including a tuple like in your example.

But it also works for ranges and generators! For instance, you can also do:

s += range(3)

The "augmented" assignment operators like += were introduced in Python 2.0, which was released in October 2000. The design and rationale are described in PEP 203. One of the declared goals of these operators was the support of in-place operations. Writing

a = [1, 2, 3]
a += [4, 5, 6]

is supposed to update the list a in place. This matters if there are other references to the list a, e.g. when a was received as a function argument.

However, the operation can't always happen in place, since many Python types, including integers and strings, are immutable, so e.g. i += 1 for an integer i can't possibly operate in place.

In summary, augmented assignment operators were supposed to work in place when possible, and create a new object otherwise. To facilitate these design goals, the expression x += y was specified to behave as follows:

• If x.__iadd__ is defined, x.__iadd__(y) is evaluated.
• Otherwise, if x.__add__ is implemented x.__add__(y) is evaluated.
• Otherwise, if y.__radd__ is implemented y.__radd__(x) is evaluated.
• Otherwise raise an error.

The first result obtained by this process will be assigned back to x (unless that result is the NotImplemented singleton, in which case the lookup continues with the next step).

This process allows types that support in-place modification to implement __iadd__(). Types that don't support in-place modification don't need to add any new magic methods, since Python will automatically fall back to essentially x = x + y.

So let's finally come to your actual question – why you can add a tuple to a list with an augmented assignment operator. From memory, the history of this was roughly like this: The list.__iadd__() method was implemented to simply call the already existing list.extend() method in Python 2.0. When iterators were introduced in Python 2.1, the list.extend() method was updated to accept arbitrary iterators. The end result of these changes was that my_list += my_tuple worked starting from Python 2.1. The list.__add__() method, however, was never supposed to support arbitrary iterators as the right-hand argument – this was considered inappropriate for a strongly typed language.

I personally think the implementation of augmented operators ended up being a bit too complex in Python. It has many surprising side effects, e.g. this code:

t = ([42], [43])
t[0] += [44]

The second line raises TypeError: 'tuple' object does not support item assignment, but the operation is successfully performed anyway – t will be ([42, 44], [43]) after executing the line that raises the error.