On 09/05/2012 12:47 PM, Hans Mulder wrote: > On 5/09/12 17:09:30, Dave Angel wrote: >> But by claiming that id() really means address, and that those addresses >> might move during the lifetime of an object, then the fact that the id() >> functions are not called simultaneously implies that one object might >> move to where the other one used to be before the "move." > Whoa! Not so fast! The id() of an object is guaranteed to not > change during the object's lifetime. So if an implementation > moves objects around (e.g. Jython), then it cannot use memory > addresses for the id() function. Which is equivalent to my point. I had mistakenly thought that Steven was claiming it was always an address, and disproving that claim by what amounts to reductio ad absurdem.
>> I think it much more likely that jython uses integer values for >> the id() function, and not physical addresses. > The id() function is guaranteed to return some flavour of integer. > > In Jython, the return values are 1, 2, 3, 4, etc., except, of course, > if you invoke id() on an object you've id'd before, you get the same > number as before. > > In current versions of CPython, you do get the (virtual) memory > address, converted to an int (or a long). But then, CPython does > not move objects. > > Maybe the next version of CPython should shift id values two or three > bits to the right, just to make sure people don't misinterpret ids as > memory addresses. > > I think i'd prefer if it would put it through one step of a CRC32. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list