[Python-Dev] Re: PEP239 (Rational Numbers) Reference Implementation and new issues

[Tim Peters]

[Guido]
> I don't think Python needs the full matrix of exact and inexact
> versions of all kind of numbers.  I see not enough need for inexact
> ints or rationals, nor for exact floats or complex numbers.

#i3 is "an inexact integer" in Scheme, but that says nothing about how it's
*implemented*.  In fact, it's almost certainly implemented as a float, much
as #e3.0 is almost certainly implemented as an integer.  Scheme hides the
internal implementation, so that the programmer doesn't need to care; the
flip side is that programmers who do care can't force the issue in a
portable way.

> So I'd like to continue our partition of numeric types as follows:
>
>          exact       |     inexact
>  ------------------------------------
>   int/long  rational | float  complex
>
> But we can do this, which is pretty much what Tim proposes in the end:
>
>   1   ->  int
>   1.0 ->  float
>
>   1r  ->  rational
>   1.0r -> rational

Yes, that's exactly what I was proposing.  s/r/#i/ and it's the same as
Scheme's rules, although Scheme doesn't promise anything about internal
representation.

> If we ever add a fixed-point decimal type, that could use 'f' for a
> suffix.  If we ever add a floating-point decimal type (like the one
> Aahz is working on -- I mistakenly called it a fixed-point type
> before) then it could use 'd' as a suffix, or it could become the
> default and we could use 'b' as a suffix to get binary floating point.

Etc.

> But I also agree with a recent trend in this thread: let's not rush
> to add syntax.  Let's first add rationals to the library.
>
> I hereby declare this thread closed.  (Ha, ha. :-)

You should have put that sentence first -- my editor still doesn't go
backwards <wink>.