[Edu-sig] Re: rationals

[Guido van Rossum]

[Kirby]
> Going to / and // makes division unambiguous again.  The former
> forces a floating point treatment, the latter an integer treatment.
> 
> An interesting question, to me, is how a built-in rational number
> type might fit into this scheme.  As I understand the current PEP,
> we're looking at again altering / such that it returns a rational
> type in some circumstances.

That's not my (current) preference.

> My suggestion is that we follow J's example and use lowercase 'r'
> (or some other letter) as part of the name of a rational, just as
> we use 1e1 to name a float.

Right.

> Then, have / return a rational if and
> only if both arguments are rationals, otherwise stick to the planned
> behavior of returning a float.

Exactly.

> This would preserve pre-existing code
> and make rationals phase in without much disruption.  Plus we're not
> going back to "ambiguous results" because the rational result,
> though of a different "type", would be essentially equivalent to
> the corresponding floating type return value.  In other words 3/2
> returns 1.5 or, if a=rat(3) and b=rat(2), then a/b returns 3r2,
> and float(3r2) returns 1.5

Except I don't like the 3r2 notation very much.  In my version it
would become 3/2r, or 3r/2; parsed as 3 / 2r and 3r / 2, respectively.

And I'd also support 1.5r as a way to spell the same value.

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