Is this a bug?

[Michael Sparks]

ajikoe at gmail.com wrote:

> when you use a = a + 'world'  python sees it as an error because of
> different type.
> 
> But when you use a += 'world'
> python will change the right into list (because a is a list). So when
> you're code become:
> a += 'world' # a += list('world')
> 
> It really helpful if you stick to use append instead of += when you
> operate list

This was part of a test case I expected to fail. I was surprised when it
passed. Passing caused a latent bug, which I fixed, and I'm preventing it's
re-occurrence by changing the way the test is written.

The value that was being updated is expected to be a _string_. However it
had the possibility of being a list of strings , *if* the code was not
making appropriate checks. The test was intended to detect that failure in
the code. The fact that f += foo succeeded where f = f + foo would fail
masked a bug. It was rewritten around moments after I discovered this, but
it struck me as rather odd.

Based on this comment from the language reference posted by Grant I'd
personally consider it to be a bug...

      "An augmented assignment expression like x += 1 can be
      rewritten as x = x + 1 to achieve a similar, but not
      exactly equal effect. In the augmented version, x is only
      evaluated once."

(I don't consider one operation succeeding and other other throwing an
exception to be similar effects)

Whilst I understand the explanations given (expected them as my post
indicated), the above comment is the one that clinches it for me.

(I also agree for example that it's good that extend takes any iterable for
example, but a PITA that += maps to extend)

That said, the bug reference mentioned above was closed with the leading
comment:

"""I think Guido said if he had it to do over, += would not be
able to take any iterable. However, that behavior has been
set in stone for several years now and it would be hard to
take away."""

   https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848812&group_id=5470

I'm now wondering whether it should be posted as a bug, if it's not likely
to be solved short of Python 3000. (ie whether I should just consider it a
wart instead... :)

(If that's really the case I'd happily consider writing a doc patch as a
warning about the behaviour)


Michael.