Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <533e64ce$0$29993$c3e8da3$5496439d@news.astraweb.com>
References: <9daf0806-02de-4447-964c-c8f8953c23e5@googlegroups.com> <lgq8th$nj4$1@speranza.aioe.org> <87ior3w740.fsf@elektro.pacujo.net> <lgqgn7$bpd$1@speranza.aioe.org> <mailman.8478.1395710470.18130.python-list@python.org> <lgqq99$v5j$1@speranza.aioe.org> <lgtsga$2ei$1@dont-email.me> <lh1h1f$ov3$1@speranza.aioe.org> <5334c38e$0$29994$c3e8da3$5496439d@news.astraweb.com> <lh4ouu$n8l$1@speranza.aioe.org> <53364327$0$29994$c3e8da3$5496439d@news.astraweb.com> <lh5iqs$j0m$1@speranza.aioe.org> <mailman.8683.1396069736.18130.python-list@python.org> <53365F55.2040302@gmail.com> <mailman.8688.1396073027.18130.python-list@python.org> <lh5vq3$c1j$1@speranza.aioe.org> <533836c4$0$29994$c3e8da3$5496439d@news.astraweb.com> <lhb0on$pcj$1@speranza.aioe.org> <op.xdltbjr05079vu@gnudebeest> <lhfatq$hrj$1@speranza.aioe.org> <mailman.8830.1396532123.18130.python-list@python.org> <lhk2pi$nnf$1@speranza.aioe.org> <mailman.8863.1396565004.18130.python-list@python.org> <533e64ce$0$29993$c3e8da3$5496439d@news.astraweb.com>
Date: Fri, 4 Apr 2014 19:11:40 +1100
Subject: Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8885.1396599103.18130.python-list@python.org>
Lines: 53
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:69651

On Fri, Apr 4, 2014 at 6:52 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> py> x = Decimal("0.7777777777787516")
> py> y = Decimal("0.7777777777787518")
> py> (x + y) / 2
> Decimal('0.7777777777787515')
>
> I've changed my mind about Python using Decimal as the default numeric
> type. I think that would send a very strong message that Python is not
> for serious numeric work.

Hmm. Good point. (I'm not familiar with your notation, by the way;
assuming x...y includes both endpoints? The first thing that comes to
mind is git's revision syntax, in which x and y would be
tags/commits/branches and that would give you everything that's in
those branches but not in their common parent. And I doubt very much
that's what you mean!) So I go back to a previous form of the
request/desire: that the AST store numeric literals as their original
strings (maybe as well as the parsed version), such that an AST
transform can replace all float literals with Decimal literals (if
they exist, or calls to Decimal and string args if they don't).

>>> print(ast.dump(ast.parse("print(0.1 + 0.2)")))
Module(body=[Expr(value=Call(func=Name(id='print', ctx=Load()),
args=[BinOp(left=Num(n=0.1), op=Add(), right=Num(n=0.2))],
keywords=[], starargs=None, kwargs=None))])

Possibly the easiest way - and maybe I should shift this part of the
discussion to -ideas - would be to have Num nodes retain additional
meta-information, in the same way that nodes retain line/column info.
Then it would be relatively simple to write a "Decimal-mode" hook for
IDLE that would turn it into a Decimal calculator instead of a binary
float calculator. Adding Decimal as a supported type (which would have
to happen if Python gets Decimal literals, but could be done in other
ways too) would help, though it's not strictly necessary.

>>> mod=ast.parse("print(0.1 + 0.2)")
>>> exec(compile(mod,"-","exec"))
0.30000000000000004

>>> mod.body[0].value.args[0].left.n=Decimal("0.1")
>>> mod.body[0].value.args[0].right.n=Decimal("0.2")
>>> exec(compile(mod,"-","exec"))
Traceback (most recent call last):
  File "<pyshell#28>", line 1, in <module>
    exec(compile(mod,"-","exec"))
TypeError: non-numeric type in Num

But it can still be done, as long as it's possible to go back to the
original string - which currently it's not, short of parsing the
entire Python program manually.

ChrisA