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

[Samuele Pedroni]

At 21:23 06.08.2003 -0400, Tim Peters wrote:
>[Samuele Pedroni]
> > care to suggest a cheap way to get such a unique integer that's
> > not the address.
>
>I'd love to, but don't know enough about Java to guess.
>
> > ...
> > otherwise I see no other way than keeping a weak identity mapping
> > from objects to integral type values, the aforementioned unique
> > integers.
>
>Then is there a reason not to do that?  Presumably only objects to which
>id() is actually applied need to become keys in such a mapping, and if so
>only id() users pay the price.

indeed is what I did, but that's why I want to reduce id(.) usage if possible


> > Likely using a type for which a counter to get fresh unique
> > integers cheaply will not overflow too quickly.
>
>If it's a weak-keyed dict you could also reuse the integer values associated
>with keys that go away.

for the moment I'm using 64 bits without reuse. I made the maybe silly 
computation that
at the (for the moment) unrealist rate of a fresh id request per 1ns, it 
will need
some years to overflow.

> > Or instead of the mapping attach such integrals value to each
> > object. The latter is not an option for Jython, because we cannot
> > attach things to general Java objects we have to deal with.
>
>Then why bring it up <wink>?
>
>Note that I don't object to introducing a mechanism that copy etc can use
>that's highly efficient under all implementations.  But the introduction of
>such a mechanism isn't sufficient reason to get rid of the current id(),
>even if id() is horridly expensive in some implementations.

yes, that would be a reasonable compromise, basically as implemented the 
new Jython id is costly a bit in speed (not so relevant) and then memory if 
one asks the id of a lot of long lived objects, so users should be aware of 
this and in case stear away from id, having copy.deepcopy etc not using 
id(.) would help with that. Deprecating maybe is too much but at least 
making users aware that id() is horridly expensive in some implementations 
<wink>.

regards.