[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

extend methods of decimal module

On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano <steve at 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
>>> t=time.time(); import decimal; time.time()-t

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?