[Python-Dev] Deprecation warning on integer shifts and such
Guido van Rossum
guido@python.org
Wed, 14 Aug 2002 21:07:37 -0400
> > In Python up to 2.2 it's inconsistent between ints and longs:
> > >>> hex(-16711681)
> > '0xff00ffff'
> > >>> hex(-16711681L)
> > '-0xff0001L' # ??!?!?
>
> The more I think about it, the more I like the suggestion
> that was made of representing this as
>
> 1x00ffff
>
> which both makes the bit pattern apparent and unambiguously
> indicates the sign, all without any assumptions about length.
That won't help with %o, %u or %x.
I don't expect there will be much of a need to write negative hex
constants in practice: people only end up creating negative numbers
using hex constants because the want to represent 32-bit bit patterns
in a signed 32-bit int. In Python 2.4, the recommended way will be to
write 0xffffffff and not worry about the fact that it's a positive
long; extensions that take bit masks will be fixed by then to deal
with this just fine (probably through the 'k' format code in
PyArg_Parse*).
The issue of printing negative hex constants is more a theoretical
issue: hex(-1) has to return *something*, and 0xffffffff simply isn't
acceptable. I'd like it to return something that evaluates back to -1
when used in a Python expression, so "-0x1" and "~0x0" are still the
best candidates.
--Guido van Rossum (home page: http://www.python.org/~guido/)