Mark Dickinson <[email protected]> added the comment:
> 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!
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue32968>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
