# id() trickery

Jerome Chan eviltofu at rocketmail.com
Sat Mar 18 21:50:34 CET 2000

```In article
<Pine.GSO.4.21.0003181444470.17415-100000 at crusoe.crusoe.net>,
japhy at pobox.com wrote:

> Well, I've broken my brain again.  Could someone explain this to me?
>
> >>> a = id(1)
> >>> a, id(1)
> (732968, 732968)
> >>> b = id(1)
> >>> b, id(1)
> (732968, 732968)
> >>> a,b,id(a),id(b)
> (732968, 732968, 732236, 732212)
> >>> a = b + 0
> >>> a,b,id(a),id(b)
> (732968, 732968, 732188, 732212)
> >>> a = b
> >>> a,b,id(a),id(b)
> (732968, 732968, 732212, 732212)
> >>> a = b + 0
> >>> a,b,id(a),id(b)
> (732968, 732968, 732188, 732212)
>
> Could someone tell me why the value returned by id(), which is just an
> int, says type(), is acting a little fruity for me?  If a and b hold the
> same integer, shouldn't they have the same value for id()?  And why do
>
> >>> a = b # and
> >>> a = b + 0
>
> have two different effects?

I'd hazard a guess. if a = b then they both point to the same address.
Makes sense since this is a simple direct assignment. Now, if you do a =
b + 0, what the interpreter will do is perform the operation b + 0 and
store this in a temporary integer and then assign the the address of the
temporary integer to a; thus you would have two different addresses.

I think.

```