On Sat, Dec 4, 2010 at 6:34 AM, James Y Knight <f...@fuhm.net> 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). > > 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. > > James >
I don't see how this related to moving vs non-moving GC. PyPy (and I believe IronPython and Java) all have fixed unique ids that are not necesarilly their addresses. The only problem is that id() computed that way is more costly performance-wise, but works. _______________________________________________ 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
