[Python-Dev] Deprecation warning on integer shifts and such
Guido van Rossum
Tue, 13 Aug 2002 09:11:18 -0400
> Here's an slightly different idea:
> Bit shifting is hardly ever done on signed data and since
> Python does not provide an unsigned integer object, most
> developers stick to the integer object and interpret its value
> as unsigned object (much like many people interpret strings
> as having a Latin-1 value). If people use integers that way,
> they know what they are doing and they are usually not interested
> in the sign of the value at all, as long as the bits stay the
> same when they pass the value to various Python APIs (including
> C APIs).
> Conclusion: Offer developers a better way to deal with unsigned
> data, e.g. an unsigned 32-bit integer type as subtype of int and
> let the bit manipulation operators return this unsigned type.
> For backward compat. make sure that common parser markers continue
> to work as they do now and add new ones for unsigned values for
> future use. PyInt_AS_LONG(unsignedInteger) would return the
> value of unsignedInteger casted to a signed one and extensions
> would be happy.
> Only if a value gets shifted beyond the first 32 bits,
> convert it to a long.
> That should solve most backward compat problems for bit
> shifters while still unifying ints and longs.
We are *already* offering developers a way to deal with unsigned data:
use longs. Bit shifting works just fine on longs, and the results are
positive unless you "or" in a negative number. Getting a 32-bit
result in Python is trivial (mask with 0xffffffffL). The Python C API
already supports getting an unsigned C long out of a Python long
--Guido van Rossum (home page: http://www.python.org/~guido/)