Zooko:  Yes; that's the sort of solution that's needed if we're not 
allowed to assume two's complement with the extraordinary value (-
sys.maxint - 1) not a trap representation.  If we are allowed to
assume this, then more efficient solutions are available.

Also, if we're not allowed to assume two's complement + no trap 
representation, then int_and, int_xor, int_or are plain wrong:

For ones' complement or sign-and-magnitude, the result of these
logical operations won't match the result of the corresponding
operations on longs, for negative operands.

For two's complement with (-sys.maxint-1) a trap representation,
int_and and int_xor should be producing a Python long instead
of a Python int in some cases: -sys.maxint ^ 1 should be -sys.maxint - 1, 
which wouldn't be representable as a Python int.

That's why I want to make these extra assumptions beyond what's
guaranteed by the C standards; working around them introduces 
inefficiencies for all implementations, for the benefit
of implementations that (probably) don't even exist.