How about adding rational fraction to Python?

[Paul Rubin]

Lie <Lie.1296 at gmail.com> writes:
> You hit the right note, but what I meant is the numeric type
> unification would make it _appear_ to consist of a single numeric type
> (yeah, I know it isn't actually, but what appears from outside isn't
> always what's inside).

That is clearly not intended; floats and decimals and integers are
really different from each other and Python has to treat them distinctly.

> > Try with a=7, b=25
> 
> They should still compare true, but they don't. The reason why they
> don't is because of float's finite precision, which is not exactly
> what we're talking here since it doesn't change the fact that
> multiplication and division are inverse of each other.

What?  Obviously they are not exact inverses for floats, as that test
shows.  They would be inverses for mathematical reals or rationals,
but Python does not have those.

> One way to handle this situation is to do an epsilon aware
> comparison (as should be done with any comparison involving floats),
> but I don't do it cause my intention is to clarify the real problem
> that multiplication is indeed inverse of division and I want to
> avoid obscuring that with the epsilon comparison.

I think you are a bit confused.  That epsilon aware comparison thing
acknowledges that floats only approximate the behavior of mathematical
reals.  When we do float arithmetic, we accept that "equal" often
really only means "approximately equal".  But when we do integer
arithmetic, we do not expect or accept equality as being approximate.
Integer equality means equal, not approximately equal.  That is why
int and float arithmetic cannot work the same way.