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