different binding behavior

[Gabriel Zachmann]

It seems to me that the following behavior of python (2.4.1) is inconsistent:

>>> a=1
>>> b=a
>>> a+=1
>>> b 1
>>> a 2
>>> a=[1,2]
>>> b=a
>>> b+=[3]
>>> a [1, 2, 3]
>>> b

[1, 2, 3]

Why was it implemented like this??

Best regards,
Gabriel.

--
/-----------------------------------------------------------------------\
| Any intelligent fool can make things bigger, more complex, |
| or more violent. It takes a touch of genius - and a lot of courage - |
| to move in the opposite direction. (Einstein) |
\-----------------------------------------------------------------------/

 

[David Wahler]

It seems to me that the following behavior of python (2.4.1) is inconsistent: [snip]
Why was it implemented like this??

Lists are mutable objects; integers are not. For a list, a += b is
equivalent to a.__iadd__(b), which is an in-place modification.

For an integer, no __iadd__ method is provided, so a += b is equivalent
to a = a.__add__(b), which is a rebinding operation rather than a
modification.

This question (or variants thereof) is asked on an almost daily basis;
please search before posting.

-- David

 

[Fredrik Lundh]

It seems to me that the following behavior of python (2.4.1) is
inconsistent:

a=1
b=a
a+=1
b 1
a 2
a=[1,2]
b=a
b+=[3]
a [1, 2, 3]
b

[1, 2, 3]

Why was it implemented like this??

assuming that you know that integers cannot modified in place, and
that += on a list is defined to be the same thing as a call to extend,
what did you expect this to do?

</F>

 

[Steven D'Aprano]

It seems to me that the following behavior of python (2.4.1) is inconsistent:

We've just had a HUGE thread arguing about this behaviour, just three or
five days ago. Let's not start it again.

In a nutshell, the behaviour is because ints are immutable and can't be
changed in place, and lists are mutable and can be changed in place.

Imagine that ints could be changed in place. Then you could do this:

x = 0
x += 1

Now the int 0 has the value of 1. So:

print 2 + 0
=> prints 3

Confusion and horror.

So of course x += 1 can't change the int in place, it has to rebind x to a
new int.

 

[Paul Rubin]

Imagine that ints could be changed in place. Then you could do this:

x = 0
x += 1

No nothing like that. Nothing stops you from having multiple int
objects with the same value. Lists, for example, are mutable, but

x = [0,1]
x += [2,3]

doesn't change what the literal [0,1] means.

 

[Gabriel Zachmann]

We've just had a HUGE thread arguing about this behaviour, just three or

five days ago. Let's not start it again.

ok, could you please point me to it?

In a nutshell, the behaviour is because ints are immutable and can't be
changed in place, and lists are mutable and can be changed in place.

Imagine that ints could be changed in place. Then you could do this:

i don't see why there should be only one instance of Int with the value 0.
But if all this has already been debated (and, apparently, my point didn't
succeed), there is no need to discuss all this over again.

In any case, thanks a lot for your response and summary.

Best regards,
Gabriel.

--
/-----------------------------------------------------------------------\
| Any intelligent fool can make things bigger, more complex, |
| or more violent. It takes a touch of genius - and a lot of courage - |
| to move in the opposite direction. (Einstein) |
\-----------------------------------------------------------------------/

 

[Steven D'Aprano]

i don't see why there should be only one instance of Int with the value 0.

"Small" ints are cached, so there may be only one instance of the int with
value 0. However, that's an implementation detail, which may change from
version to version, and is not generally true:

py> x = 0; y = 3-3
py> x == y
True
py> x is y
True

py> x = 357900001; y = 3579*100000+1
py> x == y
True
py> x is y
False

So in general, there can be many instances of int with the same value.
That's not what immutable means.