Why Python 3?

[Chris Angelico]

On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> The change from / denoting "classic
> division" to "true division" really only affects the case where both
> operands are integers, so far as I'm aware.  If you want to divide two
> integers and get a decimal result, then convert one or both of them to
> decimals first; you would have needed to do the same with classic
> division.

If float were a perfect superset of int, and the only logical superset
when you want non-integers, then it'd be fine. But if you're mixing
int and Decimal, you have to explicitly convert, whereas if you're
mixing int and float, you don't. Why is it required to be explicit
with Decimal but not float? Of all the possible alternate types, why
float? Only because...

> As for "why float" specifically, the division __future__ import has
> been around since 2.2, longer than either decimals or fractions.

... it already existed. There's no particular reason to up-cast to
float, specifically, and it can cause problems with large integers -
either by losing accuracy, or by outright overflowing.

Suppose you take an integer, multiply it by 10, and divide it by 5. In
theory, that's the same as multiplying by 2, right? Mathematically it
is. In C it might not be, because the multiplication might overflow;
but Python, like a number of other modern languages, has an integer
type that won't overflow. In Python 2, doing the obvious thing works:

x * 10 / 5 == x * 2

In Python 3, you have to say "Oh but I want my integer division to
result in an integer":

x * 10 // 5 == x * 2

Yes, I can see that it's nice for simple interactive use. You type
"1/2" and you get back 0.5. But doesn't it just exchange one set of
problems ("dividing integers by integers rounds") for another set
("floating point arithmetic isn't real number arithmetic")?

Anyway. While I think it was a mistake to bless float in that way, I'm
aware that it isn't going to change. Which is why, for anyone who's
looking at starting a project fresh, I recommend "from __future__
import division", as it'll make the port to Py3 that much easier.

ChrisA