This seems wrong:

>>> a = []
>>> b = iter(['c', 'd'])
>>> a += b
>>> c = []
>>> c + iter(['d', 'e'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "listiterator") to list

In other words, if iadd can deal with it, why can't add?

This actually works for any iterator:
>>> l = []
>>> l += 'abc'
>>> l
['a', 'b', 'c']

for any *iterable*!

> In other words, if iadd can deal with it, why can't add?

Should ['a', 'b', 'c'] + 'def' return ['a, 'b', 'c', 'd' , 'e', 'f'] or 'abcdef'?

"In the face of ambiguity, refuse the temptation to guess."

Sure, but:

>>> a = ['a', 'b', 'c']
>>> a += 'def'
>>> a
['a', 'b', 'c', 'd', 'e', 'f']

I think either way is fine (I'm probably on the side of refusing to guess), but what I don't understand is why a += b is different from a + b in this respect.

> I don't understand is why a += b is different from a + b
> in this respect.

When a is mutable, a += b updates it in-place, so there is no ambiguity: the type of a cannot change.  When you do a + b, there is no reason to treat a as more deserving than b when selecting the type of the result.

Note that immutable types are consistent:

>>> x = tuple('abc')
>>> x += 'def'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate tuple (not "str") to tuple

>>> x + 'def'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate tuple (not "str") to tuple

Hmm, that's pretty subtle. I guess I understand, at least.

Alexander, why the pending status?

Dirkjan, do you think this is a doc bug?

> why the pending status?

To me this is a way to say "I will close this next time I look unless someone will change my mind."  "pending" has a nice property that it will change to "open" once someone adds a comment.  This is exactly what I wanted in this case.

> do you think this is a doc bug?

Interestingly, I could not find any discussion of += for lists in the docs.  This maybe because "+=" is not really search friendly.  In any case, a doc bug (if any) should be reported under a separate issue.

Thanks for the explanation of pending, I thought the mysterious Roundup/browser bug had changed the status in my back.

Searching for __iadd__ gave me only library/collections; library/stdtypes says very little.

I thought it was common to requalify a bug report into a doc bug.

> I thought it was common to requalify a bug report into a doc bug.

That's upto you and OP.  My rule of thumb is if the title reads as either code or doc bug, it's ok to reclassify.  If not, it is better to open a separate issue.

Hmm, I'm still not entirely sure that += shouldn't disallow this as well, just because of the inconsistency. I understand the reasoning now, but it feels like maybe it should be an implementation detail, and it should just be disallowed (refuse to guess).

Alexander:

> When a is mutable, a += b updates it in-place, so there is no ambiguity: the type of a cannot change.  When you do a + b, there is no reason to treat a as more deserving than b when selecting the type of the result

Does this means "a += b" is not the same as "a = a + b"? I'd think this can be seen as a pitfall for python.

On Wed, Jul 21, 2010 at 2:09 AM, Ray.Allen <report@bugs.python.org> wrote:
..
> Does this means "a += b" is not the same as "a = a + b"?

For immutable a, the two are practically the same, for mutable, they
are necessarily different.   This is explained in __iadd__
documentation:

"""
These methods are called to implement the augmented arithmetic
assignments (+=, -=, *=, /=, //=, %=, **=, <<=, >>=, &=, ^=, |=).
These methods should attempt to do the operation in-place (modifying
self) and return the result (which could be, but does not have to be,
self). If a specific method is not defined, the augmented assignment
falls back to the normal methods. For instance, to execute the
statement x += y, where x is an instance of a class that has an
__iadd__() method, x.__iadd__(y) is called. If x is an instance of a
class that does not define a __iadd__() method, x.__add__(y) and
y.__radd__(x) are considered, as with the evaluation of x + y.
"""  http://docs.python.org/reference/datamodel.html?#object.__iadd__

> I'd think this can be seen as a pitfall for python.

No.  Please see PEP 203 for the rationale.
http://www.python.org/dev/peps/pep-0203/

messages: + msg110960

messages: + msg110959