A modest PEP0238 suggestion

[Delaney, Timothy]

> Actually, adding rationals can be done almost entirely without
> breaking code...  That is, *if* we adopt PEP-238 now.  Changing 1/2
> from returning a float to returning a rational won't have to break
> code, since the mathematical value of the result is the same.
> Changing it from returning 0 to returning a rational isn't any easier
> than changing it from returning 0 to returning a float -- exactly the
> same places will have to be changed.
> 
> If you're for rationals, you're for PEP-238.

I am entirely for rationals (actually, what I would *really* like is
symbolic numerics - I want 100% exact values in all cases, including
sqrt(2), and I want them to be *fast*, but I'd settle for rationals ;)

I am however leery of the assertion that changing from int/int=>float to
int/int=>rational would have no code breakage. There are many cases where
int/int=>float will give an inexact result whereas int/int=>rational would
give an exact result.

In practice, I suspect the cases where the difference would show up are
minimal, however just as going from int/int=>int to int/int=>float means you
are gaining precision (and possibly losing exactness), the same occurs with
going from int/int=>float to int/int=>rational (except you then gain
exactness).

In any case, as I have stated before, any such changes must be held over
until the next major release before they are the default behaviour.
Fortunately, the next major release is Python 3.000, which we have always
maintained could break existing code.

For the record, I intensely dislike the // notation, but I can't articulate
why. I would prefer something like ÷, but unfortunately, typing that on my
keyboard is somewhat difficult.

Tim Delaney