[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4