Stefan Krah added the comment:
My review is done. The Karatsuba function is basically a small stack machine
and very hard to prove formally as far as I can see. The algorithm is cited
in TAOCP and the subdivision is brute force tested for all combinations of
coefficient lengths of the two input
Changes by Stefan Krah stefan-use...@bytereef.org:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
STINNER Victor added the comment:
Is there some remaining work on this issue? Or can it be closed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah added the comment:
I'm almost done with my (second) self-review of mpdecimal.c. The only
functions missing are all Karatsuba functions and mpd_qpowmod().
If there are any takers, I would be very happy. For the Karatsuba functions
you'll probably need Roman Maeder's paper, which I
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset afdb0e1a9dac by Stefan Krah in branch 'default':
Issue #7652: Clean up _mpd_qinvroot() and mark it LIBMPDEC_ONLY. Use the
http://hg.python.org/cpython/rev/afdb0e1a9dac
--
Stefan Krah stefan-use...@bytereef.org added the comment:
I switched the algorithm in mpd_qsqrt() to the one from decimal.py.
Previously the square root was calculated in terms of 1/invsqrt(x).
Curiously enough this scheme _always_ seems to produce exact results
when expected, but I don't have
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I compared both implementations, and they are the same.
I noticed that on line 7537, the call to mpd_qshiftl() may goto
malloc_error;. I think there is a memory leak in this case, mpd_del(c) and
2 others lines are skipped.
Stefan Krah stefan-use...@bytereef.org added the comment:
Thanks, Amaury! -- goto malloc_error should not leak, because there's always
a jump to the out label in line 7563.
I use this idiom a lot ever since I saw it in several places in the Linux
kernel. Of course it's a matter of taste.
Stefan Krah stefan-use...@bytereef.org added the comment:
I've opened #15237 for the capsule API. I didn't add everyone to the
nosy list, since I suspect it's not of general interest.
--
___
Python tracker rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
I have a couple of questions about the proposed capsule C API. In order to
be useful, it should be possible to set temporary contexts and pass them
to functions. For example, PyDec_Add could look like:
PyDec_Add(PyObject *a, PyObject
STINNER Victor victor.stin...@gmail.com added the comment:
You may now close the issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset f6d646e30028 by Stefan Krah in branch 'default':
Issue #7652: Enable linking of _decimal.so against an installed libmpdec.
http://hg.python.org/cpython/rev/f6d646e30028
--
Stefan Krah stefan-use...@bytereef.org added the comment:
The best thing might be to use Emax=10**8-1 and Emin=-(10**8-1) throughout.
I don't think many applications depend on having Emax=10**9-1. If they do,
they'll have to use the 64-bit version.
10**6-1 would be another option. The
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
Python-bugs-list
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 730d5357 by Stefan Krah in branch 'default':
Issue #7652: Integrate the decimal floating point libmpdec library to speed
http://hg.python.org/cpython/rev/730d5357
--
nosy: +python-dev
Stefan Krah stefan-use...@bytereef.org added the comment:
We need to decide what to do with the different limits of the 64-bit and
32-bit versions:
MAX_EMAX
default context 10**9-1
64-bit 10**18-1
32-bit42500
I think it would be
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark Dickinson rep...@bugs.python.org wrote:
FWIW, I think we would be better off if this patch were merged in soon.
+1
OK, I'm counting three +1 for merging soon. Thanks everyone for the
encouragement!
I'll then proceed with the
Stefan Krah stefan-use...@bytereef.org added the comment:
Arfrever Frehtes Taifersar Arahesis rep...@bugs.python.org wrote:
Please add --with-system-libmpdec (or --with-system-mpdecimal) option in
`configure`, similarly to --with-system-expat and --with-system-ffi options.
I've added that to
Benjamin Peterson benja...@python.org added the comment:
Stefan, please feel free to commit the latest patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Mark Dickinson dicki...@gmail.com added the comment:
FWIW, I think we would be better off if this patch were merged in soon.
+1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Benjamin Peterson rep...@bugs.python.org wrote:
Speaking of inline, the inline keyword will have to go because it's not C89.
Actually the trickier instances of inline in the .c files are already
suppressed when LEGACY_COMPILER (i.e.
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
FWIW, I think we would be better off if this patch were merged in soon.
Waiting until later in the release cycle risks introducing bugs that we won't
have time to notice or fix. An early merge lets more people exercise the
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file24776/9b3b1f5c4072.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Here's a new patch that addresses several remarks:
o _decimal now has __floor__ and __ceil__methods.
o libmpdec is now in a separate directory.
o I removed the big libmpdec test suite. This is why:
- It reduces the number
Stefan Krah stefan-use...@bytereef.org added the comment:
Here's a new patch that addresses several remarks:
o _decimal now has __floor__ and __ceil__methods.
o libmpdec is now in a separate directory.
o I removed the big libmpdec test suite. This is why:
- It reduces the number
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
Please add --with-system-libmpdec (or --with-system-mpdecimal) option in
`configure`, similarly to --with-system-expat and --with-system-ffi options.
--
nosy: +Arfrever
Case Van Horsen cas...@gmail.com added the comment:
I've found some differences between decimal and cdecimal.
cdecimal 2.3 does not support the __ceil__ and __floor__ methods that exist in
decimal. math.ceil converts a cdecimal.Decimal instance into a float before
finding the ceiling. This
Stefan Krah stefan-use...@bytereef.org added the comment:
Jim Jewett rep...@bugs.python.org wrote:
Whether you need *additional* subdirectories within _cdecimal to
subcategorize the .c and .h files, I'm not sure -- because I didn't
get in deep enough to know what they should be. If the
Marc-Andre Lemburg m...@egenix.com added the comment:
Does the C version have a C API importable as capsule ?
If not, could you add one and a decimal.h to go with it ?
This makes integration in 3rd party modules a lot easier.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Stefan Krah stefan-use...@bytereef.org added the comment:
Benjamin Peterson rep...@bugs.python.org wrote:
The scripts for generating code would preferably go in a Tools/decimal
directory.
Hmm, do you mean the gen*.py scripts? The output is generated by decimal.py
and used for testing
Stefan Krah stefan-use...@bytereef.org added the comment:
Benjamin Peterson rep...@bugs.python.org wrote:
Speaking of inline, the inline keyword will have to go because it's not C89.
Do you happen to know a free compiler that builds Python but does not
understand inline? I'm asking because
Antoine Pitrou pit...@free.fr added the comment:
Do you happen to know a free compiler that builds Python but does not
understand inline? I'm asking because without testing you can never
really be sure:
You could use Py_LOCAL_INLINE, but most compilers should inline small
functions
Stefan Krah stefan-use...@bytereef.org added the comment:
Case Van Horsen rep...@bugs.python.org wrote:
cdecimal 2.3 does not support the __ceil__ and __floor__
Thanks. I'll look into that.
cdecimal.Decimal instances do not emulate the various single-underscore
methods of a decimal.Decimal
Stefan Krah stefan-use...@bytereef.org added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
You could use Py_LOCAL_INLINE, but most compilers should inline small
functions automatically, AFAIK.
At the time I wrote it I benchmarked everything. I'm pretty sure
that gcc did not inline
Antoine Pitrou pit...@free.fr added the comment:
_ctypes does not compile with icc and suncc. Unlike _ctypes, _decimal
has a fallback in the form of decimal.py. So, perhaps as an alternative
we could leave the inlines and wait for build failure reports?
Sounds good to me.
--
Stefan Krah stefan-use...@bytereef.org added the comment:
Jim Jewett rep...@bugs.python.org wrote:
implementation details. Are there are clear distinctions (type
info/python bindings/basic arithmetic/advanced
algorithms/internal-use-only/???)
I failed to mention that libmpdec also has
Stefan Krah stefan-use...@bytereef.org added the comment:
Marc-Andre Lemburg rep...@bugs.python.org wrote:
Does the C version have a C API importable as capsule ?
Not yet. I'll try to make a list with proposed function names and post it here.
If not, could you add one and a decimal.h to go
Stefan Krah stefan-use...@bytereef.org added the comment:
This issue was raised by Jim on Rietveld:
Currently, the order of arguments in Context.__init__() differs
from repr(Context):
Context()
Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9,
capitals=1, flags=[],
Jim Jewett jimjjew...@gmail.com added the comment:
On Wed, Mar 7, 2012 at 5:28 AM, Stefan Krah
stefan-use...@bytereef.org added the comment:
OK, as a basis for discussion I've added:
http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt
That is indeed very
Stefan Krah stefan-use...@bytereef.org added the comment:
Jim Jewett rep...@bugs.python.org wrote:
OK, as a basis for discussion I've added:
http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt
Starting from that URL, I don't actually find setup.py.
It's
Jim Jewett jimjjew...@gmail.com added the comment:
(1) I think this module would benefit greatly from a map explaining what each
file does, and perhaps from some reorganization.
As best I can yet tell, there are about ~130 files, over a dozen directories,
but the only ones that directly
Changes by Brian Curtin br...@python.org:
--
nosy: -brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
Python-bugs-list
Stefan Krah stefan-use...@bytereef.org added the comment:
Jim, thanks for taking a look at this.
Jim Jewett rep...@bugs.python.org wrote:
(1) I think this module would benefit greatly from a map explaining
what each file does, and perhaps from some reorganization.
Just MAP.txt in the
Stefan Krah stefan-use...@bytereef.org added the comment:
STINNER Victor rep...@bugs.python.org wrote:
How can I help to integrate this module into CPython?
It would be fantastic if you could take a look at _decimal.c, for example
to find some incompatibilities between _decimal.c and
Benjamin Peterson benja...@python.org added the comment:
The scripts for generating code would preferably go in a Tools/decimal
directory.
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
Jim Jewett jimjjew...@gmail.com added the comment:
On Tue, Mar 6, 2012 at 3:07 PM, Stefan Krah
Jim Jewett rep...@bugs.python.org wrote:
(1) I think this module would benefit greatly from a map explaining
what each file does, and perhaps from some reorganization.
Just MAP.txt in the
Benjamin Peterson benja...@python.org added the comment:
Speaking of inline, the inline keyword will have to go because it's not C89.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
Ramchandra Apte maniandra...@gmail.com added the comment:
But we could check if the compiler supports the inline keyword and use it if
available.
--
nosy: +ramchandra.apte
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
STINNER Victor victor.stin...@gmail.com added the comment:
How can I help to integrate this module into CPython?
The test suite pass in debug and release mode without any failure on my Linux
box (64 bits, running Ubuntu 11.10).
--
___
Python
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Victor, yes, the decimal module needs a C implementation. Without it, the pure
Python code is abysmally slow. Other MP implementations don't fill the need or
come close to implementing the decimal arithmetic spec.
--
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file24615/40917e4b51aa.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Over the last two months I've done a full review of all files except
_decimal.c and mpdecimal.c.
I now have additional ACL2 proofs for a couple of functions in basearith.c
(some are partial proofs), a full proof for the special case (d =
Stefan Krah stefan-use...@bytereef.org added the comment:
STINNER Victor rep...@bugs.python.org wrote:
decimal.Decimal.__truediv__() has an optional context argument, whereas
_decimal defines PyNumberMethods.
Regarding the special methods: decimal.py uses the optional context arguments
for
Stefan Krah stefan-use...@bytereef.org added the comment:
I walked into the Roundup trap again:
Decimal(9).quantize(1, ?!?!?)
Decimal('9')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
STINNER Victor victor.stin...@gmail.com added the comment:
I tried my timestamp patch with _decimal: it fails because decimal and _decimal
API is not exactly the same.
decimal.Decimal.__truediv__() has an optional context argument, whereas
_decimal defines PyNumberMethods.
Stefan Krah stefan-use...@bytereef.org added the comment:
For my part, a two-lines description of the purpose of file is enough.
OK, I'll go for small comments in the files themselves and put big
ones in separate files.
--
___
Python tracker
Stefan Krah stefan-use...@bytereef.org added the comment:
Amaury has asked for more comments (and I agree). However, I'm not sure what
level of detail would be appropriate. As an example, I've posted the full
proof of the x87 modular multiplication in umodarith.h.
Even with the Coq parts
Stefan Krah stefan-use...@bytereef.org added the comment:
Stefan Krah rep...@bugs.python.org wrote:
Would you prefer that level of detail or should I just post the core
of the algorithm?
Argh. s/post/add to comments in umodarith.h/
--
___
Python
Antoine Pitrou pit...@free.fr added the comment:
Amaury has asked for more comments (and I agree). However, I'm not sure what
level of detail would be appropriate. As an example, I've posted the full
proof of the x87 modular multiplication in umodarith.h.
Even with the Coq parts
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
2011/12/15 Stefan Krah rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Amaury has asked for more comments (and I agree). However, I'm not sure
what
level of detail would be appropriate. As an
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file23959/be8a59fcba49.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah stefan-use...@bytereef.org added the comment:
[Amaury]
Overall, I think that the mpd C library should be better separated from the
_decimal module (a bit like _ctypes, with the libffi library): its own
configure
makefile, its own test suite... which are not necessarily related
STINNER Victor victor.stin...@haypocalc.com added the comment:
Just to clarify, no decision has yet been made on *whether*
the cdecimal work should be integrated into py3k;
we'll consult python-dev on this once we've got a working branch
and performance information.
So, what is the status
Mark Dickinson dicki...@gmail.com added the comment:
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
Stefan Krah stefan-use...@bytereef.org added the comment:
Binary versus decimal
-
There is already gmpy and bigfloat, based on the heavily optimized GMP
library,
for example. Is it a license issue? Can't we reuse GMP/MPFR to offer a
Decimal API?
_decimal is a PEP-399
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark Dickinson rep...@bugs.python.org wrote:
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:
Antoine Pitrou pit...@free.fr added the comment:
If I'm interpreting this
http://mail.python.org/pipermail/python-dev/2011-August/113240.html
dialogue correctly, a complete audit down to the last line isn't
always necessary.
It is also helped by the fact you are a core developer and we
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
We've been wanting this for a long time.
Strong +1 from me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I can help with the review. Is http://bugs.python.org/review/7652/show a good
starting point? I already have some comments.
--
nosy: +amaury.forgeotdarc
___
Python tracker
Stefan Krah stefan-use...@bytereef.org added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
It is also helped by the fact you are a core developer and we trust you to
be here to do maintenance :)
Sure. The specification doesn't really change, so the work will hopefully
be limited.
Stefan Krah stefan-use...@bytereef.org added the comment:
Raymond Hettinger rep...@bugs.python.org wrote:
We've been wanting this for a long time.
Strong +1 from me.
Thank you, Raymond!
--
___
Python tracker rep...@bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
(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
Stefan Krah stefan-use...@bytereef.org added the comment:
Amaury Forgeot d'Arc rep...@bugs.python.org wrote:
I can help with the review. Is http://bugs.python.org/review/7652/show a
good starting point? I already have some comments.
Yes, that would be great. Apart from two or three changes
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file23822/bba956250186.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Stefan Krah rep...@bugs.python.org wrote:
Yes, that would be great. Apart from two or three changes that I still
need to push patch set 4 is the latest version.
Hmm, no. I'll create a slightly newer patch from Oct. 1st.
--
Changes by Cédric Krier cedric.kr...@b2ck.com:
--
nosy: +ced
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
Python-bugs-list mailing
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
Python-bugs-list
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
Changes by Stefan Krah stefan-use...@bytereef.org:
Removed file: http://bugs.python.org/file22304/9a10e3232445.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file22404/49433f35a5f8.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah stefan-use...@bytereef.org added the comment:
The latest patch is based on a relatively stable revision of 3.3. To my
knowledge, _decimal.c and decimal.py are now fully compatible in the
sense of PEP-399.
libmpdec
o New test suite with comprehensive tests against
Changes by Stefan Krah stefan-use...@bytereef.org:
Removed file: http://bugs.python.org/file15854/py3k_help_unify.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Changes by Stefan Krah stefan-use...@bytereef.org:
Removed file: http://bugs.python.org/file15855/trunk_help_unify.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Changes by Stefan Krah stefan-use...@bytereef.org:
--
hgrepos: +25
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file22303/ad05c2fdb3b2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Changes by Stefan Krah stefan-use...@bytereef.org:
Removed file: http://bugs.python.org/file22303/ad05c2fdb3b2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file22304/9a10e3232445.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Just a couple of remarks about the diff I created:
The changes to decimal.py are exploratory (i.e. done quite hastily)
and serve the purpose to fulfill PEP-399.
library/cdecimal.rst is completely out of date.
The rest should be very
Changes by Stefan Krah stefan-use...@bytereef.org:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
Stefan Krah stefan-use...@bytereef.org added the comment:
An update on the progress:
All development currently happens in my private mpdecimal repository. The
next version of mpdecimal (2.0) is finished, stable and will be released
once all tests have completed successfully. Running the whole
Mark Dickinson dicki...@gmail.com added the comment:
On Wed, Nov 3, 2010 at 3:28 AM, Case Van Horsen rep...@bugs.python.org wrote:
Has the cdecimal branch kept up with the hash value changes in 3.2?
Not sure; that's a question for Stefan.
Is there a still a chance that cdecimal could be
Case Van Horsen cas...@gmail.com added the comment:
Has the cdecimal branch kept up with the hash value changes in 3.2?
Is there a still a chance that cdecimal could be merged into 3.2?
--
nosy: +casevh
___
Python tracker rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
All outstanding issues mentioned here have been solved in Rev. 77696:
(1) New ANSI path for unknown 64bit platforms (ia64 and Alpha build
without problems now).
(2) Unified tests for decimal and cdecimal.
(3) Documentation
Stefan Krah stefan-use...@bytereef.org added the comment:
As a first step in unifying test_decimal.py and test_cdecimal.py I
would like to patch test_decimal.py in trunk and py3k. This is to
minimize differences between py3k and py3k-cdecimal.
(1) Remove test that Decimal(x) generates a copy.
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file15855/trunk_help_unify.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Unify test_decimal and test_cdecimal:
Yes, quite possible. The diff is currently 400 lines, but it should be easy to
get that down to below 100 without any loss of functionality.
I'll look into that when I'm done with the 64 bit ANSI
Stefan Krah stefan-use...@bytereef.org added the comment:
Just an update. Rev.77358 should compile and run stable on the buildbot
platforms except Alpha and ia64. I'm working on a default ANSI path for
64-bit.
--
___
Python tracker
New submission from Mark Dickinson dicki...@gmail.com:
I've created this issue to keep track of progress in merging Stefan Krah's work
on decimal in c into py3k.
We've created a branch py3k-cdecimal (with merge tracking from py3k) for this
work. When the branch is fully working and tested
Eric Smith e...@trueblade.com added the comment:
Is the intention to write Decimal.__format__ in C, too? That would be quite a
bit of work, and I'm not sure I could recommend it. But I'm not sure if your
plan is to get rid of all Python code or not.
If your plan is to rewrite absolutely
Mark Dickinson dicki...@gmail.com added the comment:
Just to clarify, no decision has yet been made on *whether* the cdecimal work
should be integrated into py3k; we'll consult python-dev on this once we've
got a working branch and performance information.
--
1 - 100 of 104 matches
Mail list logo
