What's the address for?

Avi Gross avigross at verizon.net
Mon Feb 18 15:02:49 EST 2019


Alister wrote about the meaning of the id number often displayed about a
python object:

> it is the internal id of the function - Not necessarily an address, that
is an implementation detail.

> it is not intended for use within a program & has (almost) no practical
use.

I hear that it is implementation dependent. But are there any requirements
on the implementation that allow it to have meaning? I mean is the ID
guaranteed to be unique and not reused within a session? If two things
concurrently show the same ID, are they the same in some way?

On the implementation I am using, the ID changes if I do this:

>>> a = 1
>>> id(a)
271178896
>>> a = 2
>>> id(a)
271178912
>>> a = 1
>>> id(a)
271178896

It looks like the ID of "a" can change depending on its contents. But when I
set it back to the first content, I get the same ID.

Again, on MY IMPLEMENTATION, I did an experiment to see if the constants 1
and 2 share that ID.

>>> id(1)
271178896
>>> id(2)
271178912

It seems they do. So I tried setting variable b several ways:

>>> b = 1
>>> id(b)
271178896
>>> b = a
>>> id(b), id(a)
(271178896, 271178896)
>>> a = 2
>>> (271178896, 271178896)
(271178896, 271178896)

So it does seem in this artificial case of looking at something easily
cached like an integer, that ID has these qualities.

I tried using complex and the results are a bit complex:

>>> import math
>>> a = complex("1+2j")
>>> a
(1+2j)
>>> id(a)
48066432
>>> id(complex("1+2j"))
55084360
>>> b = complex("1+2j")
>>> id(b)
55084360
>>> a = b
>>> id(a)
55084360
>>> a = complex("1+2j")
>>> id(a)
48066432
>>> c = complex(1,2)
>>> id(c)
55086880

We seem to go between two values although I am not sure why.

How about functions?

Even more confusing:

>>> def a(): pass

>>> def b(): pass

>>> id(a), id(b)
(13123280, 13201816)
>>> b=a
>>> id(a), id(b)
(13123280, 13123280)
>>> def a(): return True

>>> id(a), id(b)
(13201816, 13123280)

The above shows that making two independent (albeit otherwise minimally
identical) functions makes two different id and copying one to the other
makes them the same but then changing one gets back the same ID reused!

So, I would be hesitant about assigning much meaning to an ID. It might be
useful within an implementation when using a debugger but perhaps not much
more.

So I decided to do what maybe should be done first. Find some documentation!

If what I read is accurate, given the source, it sounds like for Cpython an
ID may be a memory address and the guarantee is that once an ID is assigned
to something it will not be reassigned to something else as long as the
object remains in effect. Well, I assume that means that anything else set
to be the same as the original as in "a = b" will share that ID. Once an
object is gone, the ID can be reused.

This may help understand some of the above results especially since memory
management may not rapidly get rid of something. I concur that there is
often not much point in using id() or even its cousin is.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Alister via Python-list
Sent: Monday, February 18, 2019 8:29 AM
To: python-list at python.org
Subject: Re: What's the address for?

On Mon, 18 Feb 2019 11:59:18 +0000, Stefan Ram wrote:

> When one prints a function, one might get something like:
> 
> <function sum.operation at 0x0000000001E71BF8>
> 
>   . The participants of my basic course asked me what the address is
>   for. I did not know.
> 
>   What's so important about the (presumed) address of a function that it
>   is shown on every stringification of each function?

it is the internal id of the function - Not necessarily an address, that is
an implementation detail.

it is not intended for use within a program & has (almost) no practical use.



-- 
Microsoft Zen - Become one with the blue screen. 

   -- From a Slashdot.org post
-- 
https://mail.python.org/mailman/listinfo/python-list




More information about the Python-list mailing list