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

Guido van Rossum guido@python.org
Tue, 08 Oct 2002 11:09:36 -0400

[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/)