Mfcttrf

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.

You can see similar reasoning elsewhere, e.g.

>>> 1,2,3.union([4,5])
1, 2, 3, 4, 5
>>> 1,2,3 + [4,5]
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'set' and 'list'

The named method of set is allowed to take multiple new elements from a list; the operator version is not - because maybe the result should be a list instead? It's ambiguous, so Python refuses to guess.

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

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)