[Python-Dev] Deprecation warning on integer shifts and such
Tue, 13 Aug 2002 12:55:52 +0200
Jack Jansen wrote:
> On Tuesday, August 13, 2002, at 02:34 , Guido van Rossum wrote:
>> Why is it so hard to get people to think about what they need? (I
>> mean beyond "I don't want anything to change" or vague things like
>> that. I am looking for an API that will make developers like Jack as
>> well as other extension developers happy, but it feels like pulling
> It feels that way because pulling teeth is probably exactly the right
> analogy: what you're doing is probably a good idea in the long run, but
> right now it hurts...
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
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.
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/