[Python-Dev] Re: Decimal data type issues

[Tim Peters]

[Paul Moore]
> ...
> FWIW, my feeling now is that Kevin's requirement is something that can
> be handled by a subclass of Decimal, or a class which contains a
> Decimal.

I should emphasize that Decimal has always been intended to be an
implementation of IBM's proposed standard for decimal arithmetic, not to
emulate some arbitrary bag of behaviors picked from a particular database,
or other app (let alone to emulate the union of all schemes in current use).
I'm especially keen to keep it "pure" at the start of its life.  There are
extensions I'd like to see too, but I'm keeping quiet about them for now
(although adding a .copy() method to context objects is clearly harmless).

> I'm not convinced by Kevin's suggestion that the operations needed
> are "hard" - code complexity can (and should) be encapsulated
> inside the subclass, and I don't see the need for runtime
> inefficiency.

The current implementation is so inefficient in so many ways I'm not
concerned about efficiency arguments at all now.  The point is much more to
get the spec implemented correctly at first.

> Specifically, I can't see why, if you can first get an (effectively,
> according to whatever rules you want to apply) exact Decimal
> representation of your "number", you can't do any further
> scaling and changing of precision, etc, entirely with Decimal
> instances, and with minimal loss of runtime efficiency.

Indeed, the individual digits are stored as individual decimal digits right
now, so picking them apart is as cheap as it gets.

> Maybe a concrete example of what Kevin is after (I have a database
> background, so I'm happy if it's based around SQL NUMBER datatypes)
> would clarify his concerns.

That's fine -- although I don't expect it to influence the first release of
Decimal (which is aimed at implementing a specific standard).