Consider: x//y != x//float(y) for some integer values of x and y.

For example, x = 2**54-1, and y = 2:

>>> x=2**54-1
>>> y=2
>>> x//y
9007199254740991L
>>> x//float(y)
9007199254740992.0
>>> _==x//y
False

I have no idea whether this should actually be a bug or not.  The 
behaviour (above) _is_ the documented behaviour (because the operands 
are documented as being converted to a common type).  But... I think 
there's a good case for computing the mathematically correct answer 
regardless of the types of the inputs.  For one thing, one of the 
reasons behind introducing the // operator was to make division the same 
regardless of whether the inputs were floating point or int.  Computing 
the mathematically correct answer (which since the answer is an integer 
is always exactly representable in Python) would be better, and simpler 
to document.