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

[M.-A. Lemburg]

Guido van Rossum wrote:
>>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()).

You are turning in circles here. Longs are not compatible
to integers at C level. That's what I was trying to
address.

Longs don't offer the performance you'd expect from bit operations,
so they are not a real-life alternative to native 32-bit or 64-bit
integers or bit fields. They are from a language designer's POV,
but then I'd suggest to drop the difference between ints and longs
completely in Py3k instead and make them a single hybrid type for
multi-precision numbers which uses native C number types or arrays
of bytes as necessary.

BTW, what do you mean by:

	"hex()/oct() of negative int will return "
	"a signed string in Python 2.4 and up"

Are you suggesting that hex(0xff000000) returns
"-0x1000000" ?

That looks like another potentially harmful change.

Is it really worth breaking these things just for the sake
of trying to avoid OverflowErrors where a simple explicit
cast by the programmer is all that's needed to avoid them ?

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/