On Sat, 18 Jun 2005, Michael Hudson wrote:
The shortest way I know of going from 2149871625L to -2145095671 is the still-fairly-gross:
v = 2149871625L ~int(~v&0xFFFFFFFF)
I suppose the best thing is to introduce an "unsignedint" type for this purpose.
Or some kind of bitfield type, maybe.
C uses integers both as bitfields and to count things, and at least in my opinion the default assumption in Python should be that this is what an integer is being used for, but when you need a bitfield it can all get a bit horrible.
That said, I think in this case we can just make fcntl_ioctl use the (new-ish) 'I' format argument to PyArg_ParseTuple and then you'll just be able to use 2149871625L and be happy (I think, haven't tried this).
Thanks for the reply. I think I will go ahead and add some extension types to Python. Thankfully, Python is extensible with new objects.
It is also useful (to me, anyway) to be able to map, one to one, external primitives from other systems to Python primitives. For example, CORBA and SNMP have a set of types (signed ints, unsigned ints, etc.) defined that I would like to interface to Python (actually I have already done this to some degree). But Python makes it a bit more difficult without that one-to-one mapping of basic types. Having an unsigned int type, for example, would make it easier to interface Python to SNMP or even some C libraries.
In other words, Since the "Real World" has these types that I must sometimes interface to, it is useful to have these same (predictable) types in Python.
So, it is worth extending the basic set of data types, and I will add it to my existing collection of Python extensions.
Therefore, I would like to ask here if anyone has already started something like this? If not, I will go ahead and do it (if I have time).