On Tue, Oct 20, 2009 at 2:15 PM, Stefan Krah stefan-usenet@bytereef.org wrote:
- 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.
- 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.
- 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