Rationals?

[Tim Peters]

[Tim Peters]
>> ...
>> There's a better implementation in the Python sandbox:
>>
>> <http://cvs.sf.net/viewcvs.py/python/python/nondist/sandbox/rational>

[Mike Meyer]
> Cool. I knew there had to be some out there, but couldn't find one in
> either PyPI or the cookbook. I picked on Rat.py because it was what I
> found.

...

> Actually, I don't like the two PEPs. Both include changes to the
> language that would surprise programmers and non-programmers as
> well as having a negative impact on performance. You should only
> get a rational if you specifically ask for a rational.

Not true of PEP 239.  The only specific thing it proposes is adding a
rational() constructor to the builtins, of course backed by a new
rational type.  Some *possible* interactions with the rest of the
language are briefly discussed in its "open issues" section.

...

>> PS:  If you simply want to *use* a high-powered rational type,
>> download gmpy and be happy tonight.

> No - it's that rationals are available in a number of other
> programming languages I use, and it seems strange that they would be
> missing from a language that comes with "batteries included".
>
> And yes, I am willing to do this work. But don't want to bother if
> there's no chance of it getting into the standard library. Creating
> yet another rational package outisde the standard library is pretty
> pointless.

If you want to use rationals in Python, gmpy is a fine way to do it today.

There's always been some interest in adding rationals to the core, but
I wouldn't say "a lot".  There was a lot more interest in adding a
decimal type to the core, and the first version of that is being
released in Python 2.4 this year.  Since the decimal type supports
user-settable precision, it can handle exact decimal-fraction + - *
operations within the bounds of the precision set, and "gracefully"
lose precision when that bound is crossed.

Many arguments in favor of rationals have been made over the last
decade, but it's unclear how many will still be made after the decimal
type becomes familiar.  For example, the historically common argument
that rationals would support exact addition of dollars-and-cents
values will lose all force.  The less common argument that it's
somehow obscene <wink> not to have a type for which 1/x*x == 1 will
still hold.

In any case, if you don't like the existing rational PEPs (which isn't
hard to understand ...), the best hope to get rationals into the core
is to ask Guido to reject the current dead-in-the-water PEPs, and
start a new alternative PEP.  I suspect you assume that adding a
library module would be exempt from the PEP process, but that's not
so.  The most relevant example is that 2.4's decimal module is a pure
Python module, and absolutely nothing in the rest of the language
changed to accommodate it -- it didn't even get a builtin constructor.
 That may change over time, but its PEP was only "selling" the Python
module we now have.