[Python-Dev] Interest in integrating C decimal module into Python?

[Stefan Krah]

Mark Dickinson <dickinsm at gmail.com> wrote:
> > 2. Would fastdec - after achieving full decimal.py compatibility - be
> >   a serious candidate?
> 
> Definitely.  As far as I know it's the only real candidate for a full
> C version of decimal right now.  Other possibilities that I'm aware of:
> 
> * I think Raymond Hettinger is working on a C version of decimal.
> I'm not sure what its current status is.  Raymond?
> 
> * There's a partially complete rewrite of decimal in C in the sandbox,
> dating from the Need for Speed sprint in 2006:
> 
> * Wrapping the decNumber library directly would make some sense,
> but I think licensing issues rule this out.

I hope I'm not spreading misinformation, but I see two problems with
the use of decNumber as an arbitrary precision library. First, the
algorithms are not optimized for large numbers. Then, you have to
define the maximum length of the coefficient *at compile time* by
setting DECNUMDIGITS.


> It's difficult to gauge the likelihood of eventual acceptance in advance,
> though.  Maybe writing a PEP would be an efficient use of time in this
> regard?  There are certainly some open issues (e.g., what to do with
> the existing Python module;  what should other Python implementations
> do).

Good, I'll do that. I mainly wanted to find out if there is fundamental
opposition against C-decimal in the standard library, but this does not
seem to be the case.


> I think my biggest concern is maintenance:  we'd be replacing
> 8500 lines of Python code in a single file, that several of the
> current core developers understand well, with 30000 (Stefan, is
> that about accurate?) lines of C in several files, that presumably
> none of the current core devs is familiar with right now.

Ok, I think we could say that the sloc-counts are around 2600 lines of
Python vs. around 11500-12500 lines of C.


> What happens when (e.g.,) the number-theoretic transform needs
> updating for one reason or another?  Stefan, do you see yourself
> having time to spend on maintenance of this code for the
> forseeable future?

Yes. Generally speaking, I expect the code to be low-maintenance.
It would be even easier if all major compilers supported exact
width C99 types and __uint128_t, but this is wishful thinking.


Stefan Krah