> 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.