[Python-Dev] Deprecation warning on integer shifts and such
Tue, 13 Aug 2002 15:56:55 +0200
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.
> 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
You are turning in circles here. Longs are not compatible
to integers at C level. That's what I was trying to
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
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 ?
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/