Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.stack.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAPTjJmqAeuFnOmW890ykPkk4L7JpgYFtFpd6uk1xAXtt2MgBMw@mail.gmail.com>
References: <mailman.9344.1397878113.18130.python-list@python.org> <7x8ur1esa5.fsf@ruckus.brouhaha.com> <CAPTjJmqAeuFnOmW890ykPkk4L7JpgYFtFpd6uk1xAXtt2MgBMw@mail.gmail.com>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Sat, 19 Apr 2014 03:25:11 -0600
Subject: Re: Why Python 3?
To: Python <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.9353.1397899558.18130.python-list@python.org>
Lines: 31
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:70373

On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico <rosuav@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.