[Python-Dev] Re: builtin_id() returns negative numbers

[Tim Peters]

[Fredrik Lundh]
> can anyone explain the struct.pack and ZODB use cases?  the first one
> doesn't make sense to me,

Not deep and surely not common, just possible.  If you're on a 32-bit
box and doing struct.pack("...i...", ... id(obj) ...), it in fact
cannot fail now (no, that isn't guaranteed by the docs, it's just an
implementation reality), but would fail if id() ever returned a
positive long with the same bit pattern as a negative 32-bit int
("OverflowError: long int too large to convert to int")..

> and the other relies on Python *not* behaving as documented (which is worse
> than relying on undocumented behaviour, imo).

I don't know what you think the problem with ZODB's integer-flavored
keys might be, then.  The problem I'm thinking of is that by
"integer-flavored" they really mean *C* int, not Python integer (which
is C long).  They're delicate enough that way that they already don't
work right on most current 64-bit boxes whenever the value of a Python
int doesn't in fact fit in the platform's C int:

    http://collector.zope.org/Zope/1592

If id() returned a long in some cases on 32-bit boxes, then code using
id() as key (in an II or IO tree) or value (in an II or OI) tree would
stop working. Again, the Python docs didn't guarantee this would work,
and the int-flavored BTrees have 64-bit box bugs in their handling of
integers, but the id()-as-key-or-value case has nevertheless worked
wholly reliably until now on 32-bit boxes.

Any change in visible behavior has the potential to break code -- that
shouldn't be controversial, because it's so obvious, and so
relentlessly proved in real life.  It's a tradeoff.  I've said I'm in
favor of taking away the sign issue for id() in this case, although
I'm not going to claim that no code will break as a result, and I'd be
a lot more positive about it if we could use the time machine to
change this behavior for 2.4.