I'm very surprised actually, to see that Python rejected the use of

fractional/rational numbers. However, when I read the PEP, I know

exactly why the proposal was rejected: People compared fractions with

integers, while it should be more fairly compared to floats.

Arguments against:

- When I use the result of / as a sequence index, it's usually an

error which should not be hidden by making the program working for

some data, since it will break for other data.

----In Python 3 (and 2 w/ __future__), the / operator would always

return floats, and floats is invalid as sequence index, even if the

value of the float is whole. Since fractions is created with the /

operator on two integers, the behavior of fractions should mimics

float. So putting fractional type as sequence index should always be

considered as error (exception), a behavior consistent with floats.

Thus, the arguments specified above has turned invalid, at least in

Python 3.

- (this assumes the same type for them:) Int is a good type in itself,

not to be mixed with rationals. The fact that something is an integer

should be expressible as a statement about its type. Many operations

require ints and don't accept rationals. It's natural to think about

them as about different types.

----I agree, ints shouldn't be mixed with rationals. But floats

could. This argument is the main reason why I said most people

compared rational with integers. Many operations that requires ints

and don't accept rationals also don't accept floats.

Other arguments:

- Slow: Doing addition and subtraction in fractions sure is expensive,

but doing division (the heaviest arithmetic operation) is extremely

fast in fractional numbers compared to in floating numbers. It is

clear that doing two integer multiplication and switching numerator-

denominator is much faster than doing a single float division.

- Memory Intensive: To represent 1/3 to infinite accuracy requires two-

integer-space (theoretically, 2 bytes). There are some numbers that

are hard to represent in fractions, yes, but in general those numbers

could be represented using two-long-space (variable-width longs). And

whenever accuracy isn't that important, it could be possible to create

a method that would lossily approximate the current fraction to an

acceptable length. Anyway, most computers nowadays is packed with

gigantic memory, why bother with such a small issue.

- Rationals must present themselves as decimal floats or it'll be

confusing: There will be no confusion in a good written code.

Progammers that writes good code would always use the 'behind-the-

scene' number, they wouldn't convert a previously 'string'ed number

back into calculation. And a convention can be created to represent a

fraction in a single line output (like * for multiplication, / for

division, they don't exist in paper maths) that would completely

eliminate any confusion of the user (well informed about the

convention, most people that never used computer before often tried to

use x and : to represent mult and div), even when the fractional

number is outputted to the foreground UI.