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

Samuele Pedroni pedronis at bluewin.ch
Thu Aug 7 04:11:13 EDT 2003

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))


CL-USER 75 : 1 > x

CL-USER 76 : 1 > x

CL-USER 77 : 1 > x

CL-USER 78 : 1 > x

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

See also implementation specific object-address function docs:


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 

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.


More information about the Python-Dev mailing list