[Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers (original) (raw)

Travis Oliphant oliphant at ee.byu.edu
Thu Jul 14 22:25:20 CEST 2005

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 fcntlioctl use the (new-ish) 'I' format argument to PyArgParseTuple 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

More information about the Python-Dev mailing list