Direct list-out-of-tuple assignment does not work

[maxpat78]

Bug report

Bug description:

I encountered a TypeError exception in a script and reproduced it in the interactive shell:

>>> t = ([1, 2, 3], [4, 5, 6])
>>> t[0] += [7]
Traceback (most recent call last):
  File "<python-input-10>", line 1, in <module>
    t[0] += [7]
    ~^^^
TypeError: 'tuple' object does not support item assignment
>>> o = t[0]; o += [7]
>>> o
[1, 2, 3, 7, 7]

Not only it raises the unexpected TypeError exception as if operating on a tuple, but the item assignment takes place: number 7 appears twice in the list!

CPython versions tested on:

3.13

Operating systems tested on:

Windows

[skirpichev]

That's expected: tuples are immutable. See e.g. https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences

but the item assignment takes place: number 7 appears twice in the list!

Yes, you just take reference to the list and then do mutation. You can do this also in other ways:

>>> t = ([1, 2, 3], [4, 5, 6])
>>> t[0][0] = 'spam'
>>> t
(['spam', 2, 3], [4, 5, 6])

[maxpat78]

@skirpichev It remains not clear to me why t[0] += [7] assigns the first 7 to the list (tuple item [0]) but, at the same time, raises the exception: if it assumes that t[0] += [7] operates on the tuple and not on the list, it should either not append the first 7 to that list or not raise an exception.

[picnixz]

The disassembly of

t = ([1, 2, 3], [4, 5, 6])
t[0] += [7]

is

  0           RESUME                   0

  1           BUILD_LIST               0
              LOAD_CONST               0 ((1, 2, 3))
              LIST_EXTEND              1
              BUILD_LIST               0
              LOAD_CONST               1 ((4, 5, 6))
              LIST_EXTEND              1
              BUILD_TUPLE              2
              STORE_NAME               0 (t)

  2           LOAD_NAME                0 (t)
              LOAD_CONST               2 (0)
              COPY                     2
              COPY                     2
              BINARY_SUBSCR
              LOAD_CONST               3 (7)
              BUILD_LIST               1
              BINARY_OP               13 (+=)
              SWAP                     3
              SWAP                     2
              STORE_SUBSCR
              RETURN_CONST             4 (None)

As you can see, the operation is actually split into two. From a reference PoV the dis of

t = ([1, 2, 3], [4, 5, 6])
x = t[0]
x += [7]
t[0] = x

is

  0           RESUME                   0

  1           BUILD_LIST               0
              LOAD_CONST               0 ((1, 2, 3))
              LIST_EXTEND              1
              BUILD_LIST               0
              LOAD_CONST               1 ((4, 5, 6))
              LIST_EXTEND              1
              BUILD_TUPLE              2
              STORE_NAME               0 (t)

  2           LOAD_NAME                0 (t)
              LOAD_CONST               2 (0)
              BINARY_SUBSCR
              STORE_NAME               1 (o)

  3           LOAD_NAME                1 (o)
              LOAD_CONST               3 (7)
              BUILD_LIST               1
              BINARY_OP               13 (+=)
              STORE_NAME               1 (o)

  4           LOAD_NAME                1 (o)
              LOAD_NAME                0 (t)
              LOAD_CONST               2 (0)
              STORE_SUBSCR
              RETURN_CONST             4 (None)

The STORE_SUBSCR essentially indicates that it's a separate operation anyway. We cannot change this behaviour though.