[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/)