RetroSearch Browse

Mon Feb 14 18:30:46 CET 2005 · https://mail.python.org/pipermail/python-dev/2005-February/051562.html

[James Y Knight]
> I think it'd be nice to change it, too. Twisted also uses a similar
> function.
>
> However, last time this topic came up, this Tim Peters guy argued
> against it. ;)
>
> Quoting
> http://mail.python.org/pipermail/python-dev/2004-November/050049.html:
> 
>> Python doesn't promise to return a postive integer for id(), although
>> it may have been nicer if it did.  It's dangerous to change that now,
>> because some code does depend on the "32 bit-ness as a signed integer"
>> accident of CPython's id() implementation on 32-bit machines.  For
>> example, code using struct.pack(), or code using one of ZODB's
>> specialized int-key BTree types with id's as keys.

Yup, it's still a tradeoff, and it's still dangerous (as any change in
visible behavior is).  It's especially unfortunate that since

    "%x" % id(obj)

does produce different output in 2.4 than in 2.3 when id(obj) < 0, we
would change that output _again_ in 2.5 if id(obj) grew a new
non-negative promise.  That is, the best time to do this would have
been for 2.4.  Maybe it's just a wart we have to live with now; OTOH,
the docs explicitly warn that id() may return a long, so any code
relying on "short int"-ness has always been relying on an
implementation quirk.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-February/051562.html below:

[Python-Dev] builtin_id() returns negative numbers