I'm a little confused by the new world order for working with integers in extension modules. At the end of the day, my question is this: Assume my extension module has an unsigned integer it wishes to return to Python. Further, assume that this unsigned integer is not really an integer as such, but more a set of bits, or some other value "encoded" in 32 bits, such as an enum. (To put it another way, the "signedness" of this value seems more random than chosen) How should I create the object to return to Python? For a concrete example. Let's say I want to return the value of the Win32 function GetVersion(). The documentation for this function declares it is an unsigned 32 bit value. The documentation then explains that to decode this value, specific bits in the value should be examined. It then expounds on this with C sample code that relies on this unsigned behaviour by using a simple "> 0x80000000" comparison to check the high bit! I see 2 choices for returning this value: * Use PyInt_FromLong() - this will give me a *signed* Python integer, but with an identical bit pattern. * Use PyLong_FromUnsignedLong() - this function will correctly be signed, but may no longer fit in 32 bits. Now, I think I am trying to stay too close to the hardware for a language like Python, but something just seems wrong with promoting my nice 32 bit value to a Python long, simply for the sake of retaining the sign for a value that the whole concept of "signed" doesn't make much sense (as it doesn't in this case, or in the case of enums etc). Any suggestions or general advice? While this case seems quite trivial, I am starting to face this issue more and more, especially as I am seeing these lovely "FutureWarnings" from all my lovely 32 bit hexadecimal constants <wink/frown> Thanks, Mark.
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