Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #41367 > unrolled thread

tuple of ids of integers or lists

Back to article view | Back to comp.lang.python

Contents

  tuple of ids of integers or lists bartolome.sintes@gmail.com - 2013-03-17 12:43 -0700
    Re: tuple of ids of integers or lists Roy Smith <roy@panix.com> - 2013-03-17 15:59 -0400
      Re: tuple of ids of integers or lists bartolome.sintes@gmail.com - 2013-03-17 13:23 -0700
        Re: tuple of ids of integers or lists Chris Angelico <rosuav@gmail.com> - 2013-03-18 07:34 +1100

#41367 — tuple of ids of integers or lists

In Python 3.3 for Windows, every list gets a different id when it is created:

>>> id([3])
46555784
>>> id([3])
47920192
>>> id([4])
46532048

But if I write a tuple asking for the ids of two lists, each list seems to get the same id:

>>> id([3]), id([4])
(43079000, 43079000)

I was expecting a tuple with two different ids. What is the reason for this behaviour?

Thanking you in advance,

[toc] | [next] | [standalone]

#41368

In article <8e66719c-5e90-4776-bba9-a11c29fba2f1@googlegroups.com>,
 bartolome.sintes@gmail.com wrote:

> In Python 3.3 for Windows, every list gets a different id when it is created:
> 
> >>> id([3])
> 46555784
> >>> id([3])
> 47920192
> >>> id([4])
> 46532048
> 
> But if I write a tuple asking for the ids of two lists, each list seems to 
> get the same id:
> 
> >>> id([3]), id([4])
> (43079000, 43079000)
> 
> I was expecting a tuple with two different ids. What is the reason for this 
> behaviour?

This is a classic little gotcha.

Object ids are guaranteed to be unique, but only for the lifetime of an 
object.  Or, to put it another way, it is guaranteed that no two objects 
that exist at the same time can have the same id.

What's happening when you do:

>>> id([3]), id([4])

Is that a list, [3], is created, its id is taken, and then the list is 
destroyed.  In this particular implementation, object ids happen to be 
the address of the object in memory.  Then, a new list, [4], is created.  
It just so happens that it gets created using the same memory block that 
was just freed by the destruction of the other list, so it ends up in 
the same place in memory.  So it gets the same id!

Kind of neat, huh?

PS -- this makes a nice interview question to see if somebody really 
understands what's happening beneath the surface.

[toc] | [prev] | [next] | [standalone]

#41370

OK. Now I understand it. 

I was confused because when two list are created in two different lines, Python gives them different ids, but when the two lists are created in the same line (in a tuple) Python gives them the same id. It doesn't really matter as these lists are just created and destroyed, as you have said.

Thank you very much for your fast answer.

[toc] | [prev] | [next] | [standalone]

#41371

On Mon, Mar 18, 2013 at 7:23 AM,  <bartolome.sintes@gmail.com> wrote:
> OK. Now I understand it.
>
> I was confused because when two list are created in two different lines, Python gives them different ids, but when the two lists are created in the same line (in a tuple) Python gives them the same id. It doesn't really matter as these lists are just created and destroyed, as you have said.
>
> Thank you very much for your fast answer.

Here's something that'll either help you understand another aspect of
Python, or totally do your head in.

>>> print(id([3]))
14485504
>>> print(id([3]))
14485504

If you print it to stdout, the id can be reused! How is this?

Here's what's going on. In interactive mode, the result of the last
expression is made available under the name _ (a single underscore):

>>> id([3])
15597160
>>> _
15597160

Integers are objects, like everything else. (Some of them are
pre-made, but big numbers like this aren't - at least, not in this
Python. But that's implementation-dependent too.) The retention of
this integer object can in some circumstances change where the next
object is stored. So you may find that some things behave differently
in interactive mode than in a script; or perhaps printing something
out instead of letting the interpreter display it will change what
happens.

You're looking into some extremely unspecified behaviour, here, so
anything is allowed to affect it. Which means you might be able to
learn all sorts of things about Python's internals! :)

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web