> It would be a bit strange if mod with a float returns a float and floordiv with a float returns an int.

Agreed: if there are floats involved (Fraction // float or float // Fraction), I think the rule should be that we simply fall back to float behaviour, and do whatever float // float does - i.e., return a float. (I'd actually prefer that a mixed Fraction-float operation be a TypeError, but that ship sailed long ago.)

OTOH, if there's a test that's explicitly checking that `my_fraction // my_float` returns something of type `int`, then the behaviour is clearly intentional. That means that we should be cautious about changing it, and also means that we probably can't change it in 3.6 or 3.7; it'll have to wait for 3.8. (But I think that's fine; this seems like a minor consistency cleanup that I would expect to affect very few people.)

It looks as though this was a part of PEP 3141 that was never fully implemented: the "Real" type there has a __floordiv__ method that looks like this:

    @abstractmethod
    def __floordiv__(self, other):
        """The floor() of self/other. Integral."""
        raise NotImplementedError

But float // float does *not* currently return an Integral:

    >>> import numbers
    >>> x = 2.3
    >>> isinstance(x, numbers.Real)
    True
    >>> isinstance(x // x, numbers.Integral)
    False

And that definitely shouldn't change: I'd argue against such a change in any case, but backwards compatibility considerations alone mean that we shouldn't change this now to return an integer. Given that, I think it's acceptable to have a mixed fraction-float floor division return a float.

A pull request would be great. Yes, please!