rationalising division (Was: Re: [Fwd: Comment on PEP-0238])

[Paul Svensson]

"John Roth" <johnroth at ameritech.net> writes:
>"Robert J. Harrison" <rjh at 3-cities.com> wrote in message
>news:7ef50c46.0107080945.30bfa5b4 at posting.google.com...
>>
>> Other thoughts
>>
>>    - Accelerating the consideration of Rationals.
>
>It's inconsistant to have a rational type, and have integer division return
>a float! Either integer division should return a rational, or we should take
>PEPs 239 and 240 out and bury them. (In fact, if integer division returns
>a rational, then there is no need for PEP 240 - 1/2 is perfectly good as
>a rational literal!
>
>If we make integer division return a float now, then we're simply creating
>another problem when we implment rationals sometime down the path.

I would guess that expecting a float and getting a rational would
cause significantly less disturbance that expecting a (truncated)
integer and getting a (non-truncated) float (or vice versa).
However, if/when Python grows support for rationals, it would annoy me
greatly if 1/2 was interpreted as anything but a literal rational,
(or at least a compile time expression yielding same (yes I know
Python currently doesn't have compile time expressions)).

Other things to consider is the ongoing work to bridge the gap
between longs and ints, ideas about fixed precision decimals, etc.
Long/long -> float or long/int -> float seems like a mistake,
but returning a rational instead makes sense (with long rationals).

There are really two issues involved in making a significant change
such as this:  Is the grass really greener on the other side ?
And if so, is there any way to get there from here ?
My impression of the discussion is that the consensus so far is 'maybe'
and 'it's too painful', and that's why we're still arguing.

I still think it's to early to bury PEP 238, as the answers
to these questions are very lightly to change when we gain
experience from other modifications to python's numerical system.
I agree that PEPs 238 and 239 definitely need to be considered
together (in which case 240 seems dubious at best),
but I'd rather see that done by slowing down then by speeding up.

If there's anything we can do right now, it would be a very small first step.
Without causing any harm to existing code, we can add the possibility
to generate warnings about int/int discarding non-zero fractions,
and a "from __future__ import div" for a div operator doing he right thing.

Then, let's keep arguing.

	/Paul