[Python-Dev] sizeof(long) != sizeof(void*)

[Samuele Pedroni]

At 22:47 06.08.2003 +0200, Samuele Pedroni wrote:
>At 22:25 06.08.2003 +0200, Martin v. Löwis wrote:
>>Samuele Pedroni <pedronis at bluewin.ch> writes:
>>
>> > but that something like id() can be cheaply offered/exposed is very
>> > much a characteristic of the underlying GC implementation that is
>> > being exploited (objects don't move)
>>
>>That is not true. id() exposes the "identity" of an object, and an
>>run-time system that has the notion of object identities (as opposed
>>to all-things-with-equal-values-are-equal) should have no difficulties
>>exposing the object identity as a number.
>
>at each time objects have all different addresses, which does not mean
>that an object will not have the same address that some other object, even
>still alive, had at some time in the past. Identity distinguishability and
>identity as a number are not the same. If you want identity as a number 
>you should
>do some work.
>

Or put in another way, you obviously don't need id(.) to implement 'is'.
Across the range of possible GC implementations there are trade-off wrt 
offering id.
In the long run limiting id() usage to the production of generic <...> 
reprs, if x-substrate reimplementability of Python is a goal, is a 
reasonable course of action.

Then uniqueness and to be constant become then nice-to-have properties, 
which can be costly but if the usage is for <...> reprs i.e. basically 
debugging, then the price can be more reasonable to pay anywhere, if users 
are informed of the trade-offs and know not to use id for some usage 
situations it is used even by the std lib in CPython right now (e.g. in 
pickle or copy.deepcopy) and have alternatives and the std lib use the 
alternatives too.

Common Lisp for example has EQ which is equivalent to Python 'is', but 
nothing like id(.):

then e.g. Xanalys LispWorks (here 4.2 under Windows) produces the 
equivalent of <...> reprs using memory addresses which can change under 
user nose:

CL-USER 61 : 1 > (setq x (make-instance 'standard-object))
#<STANDARD-OBJECT 205E848C>

...

CL-USER 75 : 1 > x
#<STANDARD-OBJECT 205E848C>

CL-USER 76 : 1 > x
#<STANDARD-OBJECT 205E848C>

CL-USER 77 : 1 > x
#<STANDARD-OBJECT 2137B734>

CL-USER 78 : 1 > x
#<STANDARD-OBJECT 2137B734>

I don't find this very user-friendly btw, but I understand the trade-offs.

See also implementation specific object-address function docs:

http://www.lispworks.com/reference/lww42/LWRM-W/html/lwref-w-426.htm#pgfId-886378

Post 1.2 Java has java.lang.System.identityHashCode(.) which is constant 
but not unique for a given object, which is what broken Jython id(.) was using.

Now Jython sports a costly but correct id(.), which makes it so 
paradoxically  that is should'nt be used for copy.deepcopy ... at least by 
Jython.

Btw, the broken id(.) bug was a long standing one, and didn't try to 
address it for the fun of getting crappy remarks. Thanks.

On a more serious note: I wonder if there is thirdy party code depending on 
copy.deepcopy/pickle memos being id keyed. I fear the answer is yes.

regards.