[Python-Dev] sizeof(long) != sizeof(void*)
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
>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
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
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
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