Unexpected results comparing float to Fraction

[Rotwang]

On 29/07/2013 17:40, Ian Kelly wrote:
> On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB <python at mrabarnett.plus.com> wrote:
>>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>>> are approximate anyway, and the float value 1/3 is more likely to be
>>> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
>>
>> At what point should it become Fraction(1, 3)?
>
> At the point where the float is exactly equal to the value you get
> from the floating-point division 1/3.

But the interpreter has no way of knowing that the value 1/3 that's been 
passed to the Fraction constructor was obtained from the division 1/3, 
rather than, say, 100000000000000001/300000000000000000 or 
6004799503160661/18014398509481984. How do you propose the constructor 
should decide between the many possible fractions that round to the same 
float, if not by choosing the one that evaluates to it exactly?

Personally the behaviour in the OP is exactly what I would expect.