> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4