[Python-Dev] Unifying Long Integers and Integers: baseint (original) (raw)

Gareth McCaughan gmccaughan at synaptics-uk.com
Tue Aug 10 16:21:55 CEST 2004

On Tuesday 2004-08-10 14:35, Skip Montanaro wrote:

>> I think it would be worth considering all the numeric types at once >> and come up with a reasonable hierarchy that includes float, complex >> and decimal types as well. (It's clear there is no "best" way to do >> that.) Dmitry> Something like following? Dmitry> object Dmitry> numeric Dmitry> integer Dmitry> int Dmitry> long Dmitry> float Dmitry> complex At some level it seems that float is a specialization of complex (w/ imag field == 0). Also, it's not clear that float or complex don't have something other than a sibling relationship to integers.

Start by thinking about the mathematical types, which have nice clear subset relationships between them:

number
  complex
    real
      integer

Python doesn't have anything between "number" and "complex" and there's no particular reason to think it ever will, so let's simplify:

number
  real
    integer

Now consider the different implementation types and fit them in:

number
  complex
  real
    (Decimal)
    float
    integer
      int
      long

I've reintroduced "complex" here as a name for the implementation type, which in some sense should really be called complex_float or something like that.

By way of clarification of the principles here, this is what would happen to the hierarchy if Python were to acquire a type for ratios of integers. I'll call that type "fraction" and the underlying mathematical type "rational". Then we'd get:

number
  complex
  real
    (Decimal)
    float
    rational
      fraction
      integer
        int
        long

(You could argue that floats are rationals really, but that's misleading even though it's true. The structure of arithmetic operations on floats isn't the same as that on rationals.)

-- g

More information about the Python-Dev mailing list