Make float.__(i/r)floordiv__ return an int

Ideas
62

and now you get inf:

In [18]: a
Out[18]: 100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

In [19]: b
Out[19]: 1e-200

In [20]: (a / b) * b + (a % b)
Out[20]: inf

Is that any better? floats have limited precision, that’s a limitation that this doesn’t make any worse. And it would actually be quite difficult for this not to be inf or an error – I don’t think anyone is proposing making a while new type of math so we can do unlimited precision computation with non-integers. (OK, I suppose you could coerce to high precision Decimal, but again, no one is proposing that)

I think the really compact way to describe this proposal (@Gouvernathor, correct me if I’m wrong) is pretty simple:

The original PEP 238 said that floor division would mean:

a//b == floor(a/b)

as simple as that – and when it was written (py2) that means it would return a float if a or b was a float – in fact, it would always return a float if you were strict about it. But it did mean:

type(a//b) == type(a/b)

Then PEP 3141 created a more consistent Type Hierarchy for Numbers, and floor(a) now returns an int.

This proposal is that a//b should return an int, so that we are back to the original idea:

a//b == floor(a/b)

and also:

type(a//b) == type(floor(a/b))

Is that so hard?

So far:

  • I don’t think anyone recalls why this wasn’t done with PEP 3141
  • Some folks think it would have been better not have made the change to floor() and ceil()
    But it’s hard to argue that the inconsistency is good.

Backward compatibility is a good thing, and that may prevent this idea from being adopted, but that’s different than it being a bad idea.