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. -- http://mail.python.org/mailman/listinfo/python-list
