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

Michael Chermside mcherm at mcherm.com
Tue Apr 20 13:23:26 EDT 2004

Kevin Jacobs writes:

It could be an add-on, but it seems a common and fundamental enough operation that it should be well supported by the core library. External implementations may be less efficient, as they cannot take advantage of the internal implementation details that a better integrated solution would offer.

This isn't something I am willing to go to war on, but at the same time, I'm willing to expend some effort to lobby for inclusion. Either way, I will have the necessary infrastructure to accomplish my aims, though my goal is for everyone to have it without re-inventing the wheel. Silence on this topic benefits nobody.

Okay, then I'll speak up too. To me it seems that a way of specifying the precision INDEPENDENT of the string representation is an unusual enough need that it does not merit inclusion in Decimal so long as it is easy to implement as an add-on.

If I receive a bunch of numbers as strings and the precision is already correct, I can use Decimal(s) to create it. If I receive a bunch of numbers as fixed position strings and need to set a fixed precision which doesn't match what the strings contain, then simple string manipulation will work:

nums = ["3.14159", "2.71828", "0.57721"]
# Pad with zeros
high_precision = [Decimal(num + "000") for num in nums]
low_precision = [Decimal(num[0:4]) for num in nums]

If I receive a bunch of numbers as variable-length or variable- precision strings or I receive precision information separately, then I may need some additional logic to create the Decimal objects. I consider that to be reasonable.

Again... just one opinion, and I don't mind if you disagree.

-- Michael Chermside

More information about the Python-Dev mailing list