[issue7652] Merge C version of decimal into py3k.
Mark Dickinson
report at bugs.python.org
Wed Nov 30 14:03:29 CET 2011
Mark Dickinson <dickinsm at gmail.com> added the comment:
> Does Python really need yet another multiprecision library?
It's not really another library: it's a reimplementation of the existing decimal library in C. The decimal library is *hugely* valuable to the financial world, but its slowness is a major concern. _decimal would help to address that concern.
> Can't we reuse GMP/MPFR to offer a Decimal API?
Nope: those are for binary floating-point. Shoehorning decimal semantics on top of a binary floating-point library is a really bad idea. (Actually, that's a part of why decimal.py is slow---it's using Python's *binary* integers to store *decimal* coefficients, so that even simple addition is now a quadratic operation, thanks to the binary <-> decimal conversions involved.)
> _decimal should maybe first be distributed as a third party library until it is really well tested and its API is > really stable.
My take is that this has already happened.
The only problem from my perspective is getting someone to find time to review such a massive patch. I've been wondering whether we could get away with some kind of 'statistical' review: do a large-scale review, and then instead of having someone go through every line of C code, pick a few representative sections at random and review those. If those code portions make it through the review unscathed, declare the code good and merge it in.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________
More information about the Python-bugs-list
mailing list