Message148652
> 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. |
|
Date |
User |
Action |
Args |
2011-11-30 13:03:29 | mark.dickinson | set | recipients:
+ mark.dickinson, rhettinger, vstinner, casevh, eric.smith, jjconti, ced, brian.curtin, skrah, eric.snow |
2011-11-30 13:03:29 | mark.dickinson | set | messageid: <1322658209.73.0.41865435677.issue7652@psf.upfronthosting.co.za> |
2011-11-30 13:03:29 | mark.dickinson | link | issue7652 messages |
2011-11-30 13:03:28 | mark.dickinson | create | |
|