Why Python 3?

[Ian Kelly]

On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico <rosuav at gmail.com> wrote:
> That'll make Python 2.6/2.7 behave like Python 3.x in three ways:
> firstly, "print" will be a function instead of a statement (and it's
> more powerful than the statement form, as well as being more
> flexible); secondly, quoted strings will be Unicode strings, not byte
> strings (that'll help you to start thinking about what's bytes and
> what's text, which is an important distinction in Python 3); and
> thirdly, though less important than the others, the division of two
> integers will result in a floating point, not an integer. I personally
> think the last one was a mistake on Python 3's part (why bless float
> specifically? what if you're working with integers and
> decimal.Decimals?), but if you're going to move to Python 3, you may
> as well have your code start working that way, so you get used to
> typing // to divide integers and get an integer (floor division).

If you're working with decimals, then the result is a decimal.  If one
side is an integer and the other is a decimal, then the result is
still a decimal.  Similarly if one of the operands is a fraction, then
the result is a fraction.  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.

We also gained a consistent and explicit way to differentiate between
the two different styles of division that classic division
represented, as opposed to picking at run-time based on type.

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