The loss is unavoidable. Floats have no more than 64 bits of
information, and that includes 1 bit for the sign. But Fractions are
limited only by the amount of memory.
x = 1 - Fraction(1, 2)**1000000
is a fraction where both the numerator and denominator have more than
300,000 digits each. (That’s about a million bits each.)
You can’t fit 20 pounds of potatoes in a 10 pound sack, and you can’t
fit two millions bits in a 64 bit float 
For every finite float, there is more than one possible numerator/
denominator pair that would be rounded to that float, even if you count
only pairs in simplified form.
(Strictly speaking, there are an infinite number of such numerator/
denominator pairs. But most of them involve ludicrously big values.)
Let’s take the three adjacent floats:
0.49999999999999994 = 9007199254740991 / 18014398509481984
0.5 = 1/2
0.5000000000000001 = 4503599627370497 / 9007199254740992
So there are a whole lot of fractions that exist within the range
0.499…4 to 0.500…1 that have to be rounded to one of those three
values. For example:
>>> float(Fraction(9007199254740993, 18014398509481984))
0.5
In principle, one of your users might genuinely expect the exact
fraction 9007199254740993/18014398509481984 and be mad that it rounds to
1/2. But it isn’t very likely.
But if you really care about this, then just use Fractions all the way
through your calculations, and don’t allow any floats to creep into the
calculation. Make sure your users only enter values as numerator,
denominator pairs, and there will never be any data loss.
Or you could just use limit_denominator with a denominator of, say,
50000 or 100000 or so. Most people aren’t going to care about fractions
with larger denominators.