[Python-Dev] Re: Decimal data type issues

[Michael Chermside]

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