Rationale for core Python numeric types

[Peter Hickman]

M. Feinstein wrote:
> I don't want to get all pissy about this, but apart from some useful
> pointers about how to deal with binary data and some not-so-useful
> suggestions about what I should go do with my problems, no one has
> answered my original question. Should I conclude that there is no
> rationale for core Python numeric types? Should I just go dunk my head
> in a pail of water and take a deep breath?

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

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.

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? Although some 
languages do in fact have subspecies of integer (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.

Hope this goes some way to helping explain things.