Python id() does not return an address [was Re: why () is () and [] is [] work in other way?]

Steven D'Aprano steve+comp.lang.python at pearwood.info
Fri Apr 27 13:12:48 EDT 2012


On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:

> On Apr 26, 5:10 am, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:

>> Solution to *what problem*?
>>
> This confusion that many people have over what 'is' does, including
> yourself.

I have no confusion over what "is" does. The "is" operator returns True 
if and only if the two operands are the same object, otherwise it returns 
False.

If you think that "is" does something different, you are wrong.

 
>> > An address is an identifier: a number that I can use to access a
>> > value[1].
>>
>> Then by your own definition, Python's id() does not return an address,
>> since you cannot use it to access a value.
> 
> The fact Python lacks explicit dereferencing doesn't change the fact
> that id() returns an address.  Replace 'can' with 'could' or 'could
> potentially' or the whole phrase with 'represents' if you wish.  It's a
> rather pointless thing to quibble over.

You can't treat id() as an address. Did you miss my post when I 
demonstrated that Jython returns IDs generated on demand, starting from 
1? In general, there is *no way even in principle* to go from a Python ID 
to the memory location (address) of the object with that ID, because in 
general objects *may not even have a fixed address*. Objects in Jython 
don't, because the Java virtual machine can move them in memory.

The fact that CPython happens to use the memory address of objects, 
suitably converted to an int object, is a red-herring. It leads to 
nothing but confusion.

 
> Would you call the result of casting a C pointer to an int an address? 
> If so, you must call the result of id() an address as well-- you can't
> dereference either of them.  If not, then you need to provide an
> alternate name for the result of casting a C pointer to an int.

I don't need to do anything of the sort. It was *your* definition, not 
mine. Don't put the responsibility on me for your definition being broken.

(And for the record, in C you can cast an integer into a pointer, 
although the results are implementation-specific. There's no equivalent 
in Python.)


-- 
Steven



More information about the Python-list mailing list