Martin v. Löwis wrote:
I'm afraid I don't follow you. Unless you're suggesting some sort of
esoteric object system whereby objects *don't* have identity (e.g. where
objects are emergent properties of some sort of distributed,
non-localised "information"), any object naturally has an identity --
itself.
Not in Java or C#. It is in these languages possible to determine
whether to references refer to the same object. However, objects don't
naturally have a distinct identification (be it an integer or something
else).
Surely even in Java or C#, objects have an *identity* even if the
language doesn't provide a way to query their distinct *identification*.
An object stored at one memory location is distinct from any other
object stored at different memory locations at that same moment in time,
regardless of whether or not the language gives you a convenient label
for that identity. Even if that memory location can change during the
lifetime of the object, at any one moment, object X is a different
object from every other object.
The fact that we can even talk about "this object" versus "that object"
implies that objects have identity.
To put it in Python terms, if the id() function were removed, it would
no longer be possible to get the unique identification associated with
an object, but you could still compare the identity of two objects using
`is`.
Of course, I'm only talking about objects. In Java there are values
which aren't objects, such as ints and floats. That's irrelevant for our
discussion, because Python has no such values.
If you really want to associate unique numbers with objects in these
languages, the common approach is to put them into an identity
dictionary as keys.
It seems counter-productive to me to bother with an identity function
which doesn't meet that constraint. If id(x) == id(y) implies nothing
about x and y (they may, or may not, be the same object) then what's the
point?
See James' explanation: it would be possible to use this as the
foundation of an identity hash table.
I'm afraid James' explanation didn't shed any light on the question to
me. It seems to me that Java's IdentityHashValue[sic -- I think the
correct function name is actually IdentityHashCode] is equivalent to
Python's hash(), not to Python's id(), and claiming it is related to
identity is misleading and confusing.
I don't think I'm alone here -- it seems to me that even among Java
programmers, the same criticisms have been raised:
http://bugs.sun.com/bugdatabase/view_bug.do?bug%5Fid=6321873
http://deepakjha.wordpress.com/2008/07/31/interesting-fact-about-identityhashcode-method-in-javalangsystem-class/
Like hash(), IdentityHashCode doesn't make any promises about identity
at all. Two distinct objects could have the same hash code, and a
further test is needed to distinguish them.
Why would you bother using that function when you could just use
x == y instead?
Because in a hash table, you also need a hash value.
Well, sure, in a hash table you need a hash value. But I was talking
about an id() function.
So is that it? Is IdentityHashValue (or *Code, as the case may be) just
a longer name for hash()?
--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com