[Python-ideas] Python Float Update

[Oscar Benjamin]

On 2 June 2015 at 14:05, Andrew Barnert via Python-ideas
<python-ideas at python.org> wrote:
> On Jun 2, 2015, at 05:34, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> This is one of the other
>> main reasons why decimal64 or decimal128 are better candidates for a
>> builtin decimal type than decimal.Decimal as it exists today (as well
>> as being potentially more amenable to hardware acceleration on some
>> platforms).
>
> OK, so what are the stumbling blocks to adding decimal32/64/128 (or just one of the three), either in builtins/stdtypes or in decimal, and then adding literals for them?
>
> I can imagine a few: someone has to work out exactly what features to support (the same things as float, or everything in the standard?),

I would argue that it should be as simple as float. If someone wants
the rest of it they've got the Decimal module which is more than
enough for their needs.

> how it interacts with Decimal and float (which is defined by the standard, but translating that to Python isn't quite trivial),

Interaction between decimalN and Decimal coerces to Decimal.
Interaction with floats is a TypeError.

> how it fits into the numeric tower ABCs,

Does anyone really use these for anything? I haven't really found them
to be very useful since no third-party numeric types use them and they
don't really define the kind of information that you might really want
in any carefully written numerical algorithm. I don't see any gain in
adding any decimal types to e.g Real as the ABCs seem irrelevant to
me.

> and what syntax to use for the literals, and if/how it fits into things like array/struct/ctypes

It's not essential to incorporate them here. If they become commonly
used in C then it would be good to have these for binary
compatibility.

> and into math, and whether we need decimal complex values,

It's not common to use the math-style functions with the decimal
module unless you're using it as a multi-precision library and then
you'd really want the full Decimal type. There's no advantage in using
decimal for e.g. sin, cos etc. so there's not much really lost in
converting to binary and back. It's in the simple arithmetic where it
makes a difference so I'd say that decimal should stick to that.

As for complex decimals this would only really be worth it if the
ultimate plan was to have decimals become the default floating point
type. Laura suggested that earlier and I probably agree that it would
have been a good idea at some earlier time but it's a bit late for
that.

> and what the C API looks like (it would be nice if PyDecimal64_AsDecimal64 worked as expected on C11 platforms, but you could still use decimal64 on C90 platforms and just not get such functions...);

Presumably CPython would have to write it's own implementation e.g.:

    PyDecimal64_FromIntExponentAndLongSignificand

... or something like that.

> then write a PEP; then write an implementation; and after all that work, the result may be seen as too much extra complexity (either in the language or in the implementation) for the benefits. But is that it, or is there even more that I'm missing?

I don't think anyone has proposed to add all of the things that you
suggested. Of course if there are decimal literals and a fixed-width
decimal type then over time people will suggest some of the other
things. That doesn't mean that they'd need to be incorporated though.

A year ago I said I'd write a PEP for decimal literals but then I got
clobbered at work and a number of other things happened so that I
didn't even have time to read threads like this. Maybe it's worth
revisiting...


Oscar