prePEP: Decimal data type

[Alex Martelli]

John Roth wrote:

> Lots of comments in line. See especially the comment
> about *NOT* wanting limited precision, as envisioned
> in the referenced decimal *floating point* standards.
   ...
> Since we've got infinite precision integer arithmetic, going to
> limited precision decimal arithmetic is, IMNSHO, a step backwards.

There may be a niche for a Rational data type, but in MHO it cannot take the 
place of a limited-precision-decimal (fixed or float).  I suggest you think 
of a separate PEP to propose Rational (check the existing and rejected ones 
first, there may be some that are relevant) rather than attacking this one.

I think Guido will never accept rationals becoming as widespread as they 
were in ABC (the default noninteger type) and is on record as saying that.
The performance implications of the fact that summing two rationals (which 
take O(M) and O(N) space respectively) gives a rational which takes O(M+N) 
memory space is just too troublesome.  There are excellent Rational 
implementations in both pure Python and as extensions (e.g., gmpy), but 
they'll always be a "niche market" IMHO.  Probably worth PEPping, not worth 
doing without Decimal -- which is the right way to represent sums of money, 
a truly major use case in the real world.

(Facundo, I think you should include these considerations in the PEP to 
explain why you're NOT going for rationals.)


>>     if otherType is a string:
>>
>>         g. an exception is raised
>>         h. otherType is converted to Decimal
>>         i. Decimal is converted to string (bizarre, huh?)
> 
> The "other type" should be handled in the same way the decimal()
> constructor would handle it.

I think this total breach with Python tradition would be a terrible mistake.

23+"43" is NOT handled in the same way as 23+int("45"), and a VERY
good thing that is too.  It's a completely different thing for a user to 
EXPLICITLY indicate they want construction (conversion) and to just happen 
to sum two objects one of which by mistake could be a string.

(Facundo, perhaps it's worth it for the PEP to point this out explicitly, 
too; part of a PEP's purpose is to record the highlights of the discussion 
and design choices that had to be made).


Alex