James Y Knight wrote:
On Dec 3, 2010, at 10:50 PM, Terry Reedy wrote:
On 12/3/2010 7:46 PM, James Y Knight wrote:
Sure they are. This is what Java provides you, for example. If you
have fixed, but potentially non-unique ids (in Java you get this
using "identityHashCode()"), you can still make an identity
I do not see the point of calling a (non-unique) hash value the identity
My point was simply that a) it's an unfortunate constraint on potential GC implementations that objects need to have a fixed and unique id in Python, and b) that it's not actually necessary to have such a constraint (in the abstract sense of required; obviously it's a requirement upon Python *today*, due to existing code which depends upon that promise).
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.
It seems to me that an identify function must obey one constraint:
* Two objects which exist simultaneously have the same identity if
and only if they are the same object i.e. id(x) == id(y) if and
only if x is y.
Other than that, an implementation is free to make id() behave any way
they like. CPython uses the memory location of the object, but Jython
and IronPython use an incrementing counter which is never re-used for
the lifetime of the Python process. CPython's implementation implies
that objects may not be moved in memory, but that's not a language
constraint, that's an implementation issue.
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? Why would you bother using that function when you could just use
x == y instead?
Would you be happier if I had said "it's unfortunate that Python has an "id" function
instead of an "identityHashValue" function? I suppose that's what I really meant. Python the
language would not have been harmed had it had from the start an identityHashValue() function instead of
an id() function. In the CPython implementation, it may even have had the exact same behavior, but
would've allowed other implementations more flexibility.
No, because I don't see what the point of identityHashValue or why you
would ever bother to use it.
--
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
