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

[Mark Dickinson]

On Tue, Oct 20, 2009 at 2:15 PM, Stefan Krah <stefan-usenet at bytereef.org> wrote:
> 1. Are you generally in favour of a C decimal module in Python?

I'm certainly interested in the general idea;  whether I'd be in favour
of replacing decimal.py with a particular C version would depend on
a lot of factors, with code quality, interchangeability with the current
decimal module, and maintainability by Python core developers
high on the list.  There's also the question of what IronPython
and Jython would do.

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

http://svn.python.org/view/sandbox/trunk/decimal-c/

Last time I looked at this it wasn't up to date with the decimal
specification:  I'm not sure that functions like exp, log and log10
are currently working.  Georg Brandl might know better than I do.

> 3. Could I use this list to settle a couple of questions, or would perhaps
>   a Python developer be willing to work with me to make it compatible? I'm
>   asking this to avoid doing work that would not find acceptance afterwards.

I don't see why not.  Working closely with one of the core developers
on this sounds like a good idea, as well:  if the code were to go into
Python core, at least one (and preferably more than one) core dev
should be familiar enough with it for maintenance.  (BTW, I think that
*if* fastdec went in it's likely you'd be granted commit privileges at
some point.)

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

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

BTW, does anyone know the current SLOC count for py3k?

Mark