# [Python-Dev] Deprecation warning on integer shifts and such

**Martin v. Loewis
**
martin@v.loewis.de

*14 Aug 2002 20:46:04 +0200*

Oren Tirosh <oren-py-d@hishome.net> writes:
>* >>> hex(-16711681)
*>* '0xff00ffff'
*>* >>> hex(-16711681L)
*>* '-0xff0001L' # ??!?!?
*[...]
>* The hex representation of longs is something I find quite misleading and
*>* I think it's also unprecedented. This wart has bothered me for a long
*>* time now but I didn't have any use for it so I didn't mind too much. Now
*>* it is proposed to extend this useless representation to ints so I do.
*
I don't find it misleading - in fact, the C representation is
misleading: 0xff00ffff looks like a positive number (it does not have
a sign) - this is misleading, as the number is, in fact, negative.
The representation is not misleading: it does not make you believe it
is something that it actually isn't. It might be surprising, but after
thinking about it, it should be clear that it is correct: -N is the
number that, when added to N, gives zero. Indeed:
>>>* -16711681L+0xff0001L
*0L
If you want the bitmask for the lowest 32 bits, you can write
>>>* hex(-16711681L & (2**32-1))
*'0xFF00FFFFL'
Notice that -16711681 is a number with an infinite amont of leading
ones - just as 16711681 is a number with an infinite amount of leading
zeroes.
Regards,
Martin