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

**Paul Svensson
**
paul-python@svensson.org

*Wed, 14 Aug 2002 15:21:57 -0400 (EDT)*

On 14 Aug 2002, Martin v. Loewis wrote:
>*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.
*
Just a thougth: if it's true that those using hex() and %x are more
interested in the bit values than the numerical value of the whole number,
would a format like ~0xff000 be easier to interpret (and stop this debate) ?
/Paul