On Fri, Apr 01 2011, Ruchir Shukla wrote:
> Hello,
>
> This is just because you are changing the value of b and in foo there is a
> reference of b.
>
> while in
>>>> foo = (1,[2,3,4])
>>>> foo[1] += [6]
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment
>>>> foo
> (1, [2, 3, 4, 6])
>>>>
> it is changing the value in List but after that python has realized that the
> error .
I like your use of "realized". Sort of like "Oops. I'm sorry I shouldn't
have done that but I've half messed things up already". :)
I can explain this behaviour just fine. Two operations etc.
BG's thing about append can be explained I think with a disassemble.
>>> def foo():
... x = []
... x += [1]
...
>>> def bar():
... x = []
... x.append(1)
...
>>> dis.dis(foo)
2 0 BUILD_LIST 0
3 STORE_FAST 0 (x)
3 6 LOAD_FAST 0 (x)
9 LOAD_CONST 1 (1)
12 BUILD_LIST 1
15 INPLACE_ADD
16 STORE_FAST 0 (x)
19 LOAD_CONST 0 (None)
22 RETURN_VALUE
>>> dis.dis(bar)
2 0 BUILD_LIST 0
3 STORE_FAST 0 (x)
3 6 LOAD_FAST 0 (x)
9 LOAD_ATTR 0 (append)
12 LOAD_CONST 1 (1)
15 CALL_FUNCTION 1
18 POP_TOP
19 LOAD_CONST 0 (None)
22 RETURN_VALUE
With `foo`, I think either STORE_FAST will alter an
element of the tuple so it will die but by the time INPLACE_ADD has
already taken place so the list has been modified.
Would anyone here characterise this as a bug?
[...]
--
_______________________________________________
BangPypers mailing list
BangPypers@python.org
http://mail.python.org/mailman/listinfo/bangpypers
