A related problem is that float(n) isn't always correctly rounded for an integer 
n.  A contrived example:

>>> n = 2**68 + 2**16 - 1
>>> float(n)
2.9514790517935283e+20

Here the difference between float(n) and the true value of n is around 0.99998 
ulps;  a correctly rounded float() would have error at most 0.5 ulps.

I don't regard this as terribly serious: from looking at the code, I *think* 
it's always true that the error is strictly less than 1 ulp, which is just 
enough to guarantee that float(n) == n whenever n is exactly representable as a 
float.

In contrast, the division of two integers can produce results that are up to 3.5 
ulps out from the true value.  This is, in my opinion, a worryingly large error 
for a simple calculation.