How about adding rational fraction to Python?

J. Clifford Dyer jcd at sdf.lonestar.org
Tue Feb 26 20:32:26 EST 2008


On Tue, 2008-02-26 at 14:08 -0800, Jeff Schwab wrote:
> J. Cliff Dyer wrote:
> > On Tue, 2008-02-26 at 13:51 -0500, D'Arcy J.M. Cain wrote:
> >> On Tue, 26 Feb 2008 13:39:38 -0500
> >> "J. Cliff Dyer" <jcd at sdf.lonestar.org> wrote:
> >>>>>> a = 20000 * 20000
> >>>>>> b = 200000 * 200000
> >>>>>> type(a)
> >>> <type 'int'>
> >>>>>> type(b)
> >>> <type 'long'>
> >> A long int is still integral which is the crux of the issue.
> >>
> > 
> > So do you believe that you should not be able to do natural division
> > without explicitly casting ints as floats, or is your concern just that
> > you want to still be able to to integer division simply?
> 
> I think the issue is whether this qualifies as "natural" division in the 
> first place.  (For the record, I'm only semi-old-school.)

OK.  My use of the word "natural" was ill advised.

Sorry.

But I don't think that *was* the issue in the first place.  The issue is
whether python's division should only yield integers when given integer
inputs.  "Natural" is a polemical term no matter who is using it in this
argument, so lets drop it altogether.  If the issue is that it should
remain an integer because that mimics how the computer works, than I
think it is worth pointing out that allowing a conversion to a long also
goes against how the computer works; the computer would have a register
overflow.  If the issue is that in python the division operator has
always performed integer division, and should not change, then I think
we're talking about a philosophical opposition to Python 3 that goes far
deeper than just how integer division behaves.

At any rate, the whole argument is irrelevant--python already supports
floating point results for integer division, and that isn't going away,
but neither is integer division that always results in integer results,
so if you don't like getting floating point results, you never have to
use the / operator.  

Practicality beats purity.  

Cheers,
Cliff




More information about the Python-list mailing list