Rationale for core Python numeric types

[Grant Edwards]

On 2004-07-16, Peter Hickman <peter at semantico.com> wrote:

> I'll try to give this a shot. The data types you talk about
> are machine types, int long, unsigned long long, float,
> double, unsigned char - they all exist as a function of the
> hardware that they run on.

I disagree.  

Things like "eight-bit signed 2's compliment binary number"
have completely rigorous definitions that are not dependent on
some particular hardware platform.  The same is true for
operations on such types.  There's nothing platform or machine
defendant about the definition of what the 1's compliment of a
16-bit binary number is.

> When you are programming in a structured macro assembler such
> as C (and to some extent C++) then these things are important,
> you can optimise both speed and storage by selecting the
> correct type.

No, I think you're missing the point. We're talking about
writing a Python program who's purpose is to manipulate
externally defined data in externally defined ways.  The data
are binary numbers of specific lengths (typically 8, 16, and 32
bits) and the operations are things like 1's compliment, 2's
compliment, 2's compliment addition and subtraction, left and
right shift, binary and and or, etc.

> Then you port your code and the two byte int turns into four
> bytes, structures change size as they data aligns itself to
> even (or is it odd) word boundaries - like it does on the
> m68k.

That's true but irrelevant.  The layout of a TCP header doesn't
change depending on the platform on which the TCP stack is
running.  [And, yes, I do use Python to implement protocol
stacks.]

> Python, along with other languages of this class, abstract
> away from that. You have integers and floats and the language
> handles all the details. You just write the code.

What if my algorithm doesn't require "just an integer".  What
if my requirement is for an "8-bit 2's compliment binary
integer"?

> If you look at the development of C from it's roots in B you
> will see that all these variants of integers and floats was
> just to get a correct mapping to the facilities supplied by
> the hardware and as long as languages were just glorified 
> assembler then to get things to work you needed this menagerie
> of types.
>
> Python sits between you and the hardware and so what use is an
> unsigned integer if you are not going to be able to directly
> access the hardware?

You seem obsessed with hardware. :) 

I'm not talking about manipulating hardware.  I'm talking about
implementing externally defined algorithms that specify the
data types and operations to be performed.  I'm talking about
things like manipulating the fields within a TCP header,
calculating an IP checksum, tearing apart an IEEE-754 floating
point value, etc.

I don't care if the underlying hardware on which I'm running
Python is trinary logic and integers are represented in TCD --
I still need to write Python programs to perform operations on
fixed-length binary numbers.  In "old" python, it was sometimes
handy to rely on the assumption that an integer was 32-bits: it
prevented you from having to continually and everything with
0xffffffff to force the result back into the proper domain.  It
would be equally handy to have 8 and 16 bit integer types so I
didn't have to keep anding things with 0xff and 0xffff.

I have no quarrel with the argument that I shouldn't use Python
integer objects for these operations, and that I should
implement a class of 'fixed-length-binary-2's-compliment-number'
objects if what I want is to operate on fixed length binary 2's
compliment numbers.  However, don't try to tell me that I don't
_need_ to use fixed-length binary 2's compliment numbers.

> Although some languages do in fact have subspecies of integer

Like C has int8_t, uint8_t, int16_t, etc.  Types like that are
utterly invaluable when what you need a 16-bit unsigned integer
regardless of platform.

> (Ruby has integer and big integer but converts between the
> subtypes as required, the Java VM defines it's types
> regardless of the facilities the hardware) the default integer
> is pretty much hardware neutral.

Don't care about hardware -- at least not the hardware on which
I'm running Python.

> Hope this goes some way to helping explain things.

Me too.

-- 
Grant Edwards                   grante             Yow!  My NOSE is NUMB!
                                  at               
                               visi.com