[Python-Dev] Re: Decimal data type issues (original) (raw)

Tim Peters tim.one at comcast.net
Wed Apr 21 20:44:34 EDT 2004

[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).

More information about the Python-Dev mailing list