[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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com