40.9//2 give 20.0 as a result.  I would have expected one of: 20.45 or 20.  If it is going to give an FP answer then it should do the division as FP and get the right answer.  If it is going to do an integer division then it should give the division as an integer.

To get 20.45 use the true division operator /.

If float // int would return int, 1e300 // 2 would return a 300-digit integer. It takee more memory and its creation is slower than 5e299. In addition it does not make sense to provide such precision.

Although it often gets called "integer division", that's not actually what // does, it is actually *floor* division, as documented here:

https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex

So the behaviour as given is correct: it returns the floor of the quotient. Arguments are coerced to a common type in the normal fashion, so float//int performs the floor  division in floating point, which may not give the same result as integer floor division due to floating point rounding:

py> 10**17 // 7
14285714285714285
py> 1e17 // 7
1.4285714285714284e+16

If you don't want floating point rounding, don't use floats.

If you want "true division", use / not the floor division operator.

This isn't a bug, it is working as designed.

Even if the behaviour you are asking for was possible, practical and desirable, it would break backwards compatibility. There's no way to do a "floor division that returns an int" for all float arguments, since there are no int NANs.

py> float('inf')//7
nan