Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3a.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: <53103c03$0$11113$c3e8da3@news.astraweb.com>
References: <02cdd9c7-aef7-4cc7-a813-cd1c9627ceb4@googlegroups.com> <mailman.7160.1392836388.18130.python-list@python.org> <94b1962a-0004-4c5b-b484-972a166b88b5@googlegroups.com> <CAKJDb-NaZmLysq+2KWgd_f4UPKCk7jdLZkvcCM6ECL5TSAwCRQ@mail.gmail.com> <mailman.7165.1392847869.18130.python-list@python.org> <55525f2c-fd3a-4927-b642-2dbf5eae7e9b@googlegroups.com> <mailman.7422.1393512211.18130.python-list@python.org> <360e87d2-4daf-4222-8ebe-51f3e4d1fade@googlegroups.com> <mailman.7429.1393518292.18130.python-list@python.org> <9f7b535f-9e5d-45df-96f6-6cd8f6b4a524@googlegroups.com> <530fff58$0$11113$c3e8da3@news.astraweb.com> <f5305bab-c526-420c-8590-d73ff318ee9c@googlegroups.com> <mailman.7454.1393563614.18130.python-list@python.org> <53103c03$0$11113$c3e8da3@news.astraweb.com>
Date: Fri, 28 Feb 2014 19:52:45 +1100
Subject: Re: extend methods of decimal module
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.7461.1393577568.18130.python-list@python.org>
Lines: 55
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:67208

On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Fri, 28 Feb 2014 16:00:10 +1100, Chris Angelico wrote:
>
>> If we had some other tag, like 'd', we could actually construct a
>> Decimal straight from the source code. Since source code is a string,
>> it'll be constructed from that string, and it'll never go via float.
>
> Now that Python has a fast C implementation of Decimal, I would be happy
> for Python 4000 to default to decimal floats, and require special syntax
> for binary floats. Say, 0.1b if you want a binary float, and 0.1 for a
> decimal.

Maybe, but I believe the cdecimal module is still slower than typical
floating point. There'd also be considerations regarding NumPy and how
you'd go about working with an array of non-integer values, and so on.
Certainly this will be an extremely reasonable topic of discussion
once there's any notion of a Py4K on the cards. There'll be arguments
on both sides.

> But for now, backwards-compatibility requires that the default floating
> point type remains binary float. But we could maybe agitate for a 1.234d
> Decimal literal type. Care to write a PEP?
>
> :-)

Heh. Strong consideration here: it would mean importing the decimal
module on startup.

>>> t=time.time(); import decimal; time.time()-t
4.5000159740448
>>> t=time.time(); import decimal; time.time()-t
0.0

A dummy import (when it's already loaded) is so fast that it's
immeasurable, but four and a half seconds to load up decimal? This is
3.4.0b2 on Windows, btw. It was a lot quicker on my Linux box,
probably because the OS or disk cache had the file. So maybe it
wouldn't be too bad in practice; but it's still a cost to consider.

>> The question is how far Python wants to bless the Decimal type with
>> syntax - after all, if Decimal can get a literal notation, why can't
>> Fraction, and why can't all sorts of other types? And that's a huge can
>> of worms.
>
> I like Fractions, but I don't think they're important enough for the
> average users to require literal notation.

Yeah, but where do you draw the line? Either decimal.Decimal becomes a
built-in type, or there needs to be a system for constructing literals
of non-built-in types. And if Decimal becomes built-in, then why that
and not <<insert type name here>>?

Also, if Decimal becomes a built-in type, does that affect the numeric tower?

ChrisA