[Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

[Travis Oliphant]

Keith Dart wrote:

>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)
>>>>>          
>>>>>
>>-2145095671
>>
>>    
>>
>>>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).
>
>  
>

I should make you aware that the new Numeric (Numeric3 now called 
scipy.base) has a collection of C-types that represent each 
C-datatype.   They are (arguably) useful in the context of eliminating a 
few problems in data-type coercion in scientific computing. 

These types are created in C and use multiple inheritance in C.  This is 
very similiar to what you are proposing and so I thought I might make 
you aware.  Right now, the math operations from each of these types 
comes mostly from Numeric but this could be modified as desired. 

The code is available in the Numeric3 CVS tree at the numeric python 
sourceforge site.


-Travis Oliphant