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

[Guido van Rossum]

[Tim]
> Noting that Scheme has two sets of optional numeric literal prefixes:
[...]
> This avoids conflating exactness with representation, and, e.g.,
{...]
> By default, a numeric literal is inexect iff it contains a radix
> point or an exponent, but #e or #i can override that.
[...]
> I think this works very well.  The same rule about default exactness
> would be appropriate for Python too, and an r suffix meaning what a
> #e prefix means in Scheme would be a fine idea by my lights (the
> effect of an #i prefix can be gotten via including a decimal point
> for decimal literals, and inexact literals in other bases are rarely
> useful).

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

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.

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

--Guido van Rossum (home page: http://www.python.org/~guido/)