Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Random832 <random832@fastmail.com>
Newsgroups: comp.lang.python
Subject: Re: for / while else doesn't make sense
Date: Sun, 22 May 2016 13:25:24 -0400
Lines: 38
Message-ID: <mailman.1.1463937929.20402.python-list@python.org>
References: <CAHJ7fxhOeKFbu3=Jso=wgpBnH9Opr_J_6SHLDO+KtAqVFeGHnA@mail.gmail.com> <mailman.36.1463676220.27390.python-list@python.org> <dq71srF3j00U1@mid.individual.net> <573EC62F.4090401@lucidity.plus.com> <CAKJDb-Nj=Wr2=3ZL3n=xRCiCa6qVmyRX1P47Wvvy7EAw1izjLQ@mail.gmail.com> <d95ba62e-0acb-d0df-8eca-7b748d4730bb@icloud.com> <mailman.57.1463775663.27390.python-list@python.org> <573f9322$0$1616$c3e8da3$5496439d@news.astraweb.com> <slrnnjvbhs.krr.jon+usenet@wintry.unequivocal.co.uk> <CAPTjJmp3FK7qeAPRmmY_9u8dg8DMB16uejHtzewkm=d6Rbo8qg@mail.gmail.com> <mailman.63.1463796315.27390.python-list@python.org> <slrnnk3fv0.krr.jon+usenet@wintry.unequivocal.co.uk> <87d1oe2l7z.fsf@elektro.pacujo.net> <1463937924.1827012.615232721.2982AD4D@webmail.messagingengine.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
In-Reply-To: <87d1oe2l7z.fsf@elektro.pacujo.net>
Precedence: list
Xref: csiph.com comp.lang.python:108951

On Sun, May 22, 2016, at 10:58, Marko Rauhamaa wrote:
> Scheme has the best of both worlds:
> 
>    scheme@(guile-user)> 2/3
>    $1 = 2/3
>    scheme@(guile-user)> (exact->inexact $1)
>    $2 = 0.6666666666666666

Why shouldn't Python do this?

Imagine some future version of Python:
>>> x = 2/3
>>> x
(2/3)
>>> type(x)
<class 'rational'>
# if it's going to be so integrated into the language it's
# hardly sensible to keep calling it 'fractions.Fraction'
>>> float(x)
0.6666666666666666

On Sun, May 22, 2016, at 11:52, Jon Ribbens wrote:
> No, it *adheres* to the principle of least surprise. Floats appearing
> out of nowhere is surprising. Python 2's behaviour adhered to the
> principle, and Python 3's breaks it.

Disregarding for the moment the particular imperfections of the float
representation (which would be gone if we used Fraction instead), this
is only true if the concrete types of results are regarded as part of
the result rather than as an implementation detail for how best to
return the requested value.

I think it would be entirely reasonable for Fractions to not only appear
out of nowhere, but to *disappear* when an operation on them yields a
value which is an integer.

Values are more important than types. Types are less important than
values.