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

[Guido van Rossum]

> 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.

-100.

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
(PyLong_AsUnsignedLong()).

--Guido van Rossum (home page: http://www.python.org/~guido/)