[issue7652] Merge C version of decimal into py3k.

Stefan Krah report at bugs.python.org
Thu Mar 8 01:06:14 CET 2012


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Jim Jewett <report at 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 the setup.py from the Python top level directory.

> I'm not sure what sort of failures building in the normal order led
> to, but that is certainly something worth documenting, and (ideally)
> fixing.

I do not have access to AIX. On Windows the failures were locale related
when mixing the dynamic and static runtimes.

> I didn't see any mention of the literature subdirectory, which makes
> me wonder if there were other files not listed in the map.  (Not yet
> curious enough to verify for myself, though.)  (*.txt files?)

FILEMAP.txt was intended to get people started, not to be a polished work.

> I suppose a subdirectory name like "python" makes sense when you look
> at the library as a C/C++ project that happens to provide python
> bindings; as part of the python core, it is misleading.

OK.

> provide extra functionality, or to generate some of the source code,

There is no source code generation. I'm not sure where this idea comes
from. genlocale.py e.g. has this comment:

Usage:  ../../../python genlocale.py | ../tests/runtest -

> Within the library, does io.[ch] really limit itself to ASCII?  If so,
> then I don't know why you're worried about the Turkish i.  If you mean
> generic text, then please don't specify ASCII.

I do mean ASCII. Please run this gdb session:

diff --git a/Modules/_decimal/io.c b/Modules/_decimal/io.c
--- a/Modules/_decimal/io.c
+++ b/Modules/_decimal/io.c
@@ -245,7 +245,7 @@
                if (digits > (size_t)(ctx->prec-ctx->clamp))
                        goto conversion_error;
        }
-       else if (_mpd_strneq(s, "inf", "INF", 3)) {
+       else if (strncasecmp(s, "inf", 3) == 0) {
                s += 3;
                if (*s == '\0' || _mpd_strneq(s, "inity", "INITY", 6)) {
                        /* numeric-value: infinity */

gdb ../../python
b mpd_qset_string
r
>>> locale.setlocale(locale.LC_ALL, 'tr_TR.utf8')
'tr_TR.utf8'
>>> from decimal import *
>>> Decimal("Infinity")

(gdb) 
248             else if (strncasecmp(s, "inf", 3) == 0) {
(gdb) p s
$1 = 0x7ffff7191280 "Infinity"
(gdb) p s[0]
$2 = 73 'I'
(gdb) n
259                     if ((coeff = scan_dpoint_exp(s, &dpoint, &exp, &end)) == NULL)

Clearly 'I' is ASCII and strncasecmp fails, exactly as written in the
comment above _mpd_strneq().

> Within memory.[ch], how much of this configurability is useful (or
> even available) to a python user, as opposed to an extension writer?

Since it is in the libmpdec section, "User" refers to the extension writer.
I can simply drop the "User".

> Under the Bignum section, it mentions that functions from these files
> are ultimately used in _mpd_fntmul, but doesn't mention where that is
> (in the main _cdecimal.c)

OK.

> Also, when it talks about "large arrays", could you clarify that it
> isn't talking about arrays of values or even matrixes, it is just
> talking about numbers large enough that even representing them takes
> at least N bytes?

But it is referring to abstract sequences or arrays of values less
than a certain prime. These values happen to be the coefficient of
an mpd_t, but you could perform the transform on any sequence.

I thought 'Bignum' would already imply an array of machine words
representing a number.

> >> Would it at least be OK to wrap them in stubs for exporting, so that
> >> the test logic could be places with the others tests? ??(I worry that
> >> some tests may stop getting run if someone else modifies the build
> >> process and doesn't notice the unusual location.)
> 
> > tests/runtest.c won't compile then. I'll look into the stub and also
> > the _testhelp suggestions.
> 
> OK, let me rephrase.  Is newton division exported to users, or used
> internally, or is it just for testing purposes?

It's used internally as _mpd_qbarrett_divmod(). When the coefficient has
more than MPD_NEWTONDIV_CUTOFF words, the division functions dispatch
to _mpd_qbarrett_divmod().

> _mpd_qtest_newtondiv is documented as a testcase; I would rather see
> it move to a test file.  Why can't it?

I said in my last mail that I'll look into it.

> >> > "Infinity", "InFinItY", "iNF" are all allowed by the specification.
> 
> >> OK; so is io.c part of the library, or part of the python binding?
> 
> > I see a potential source of confusion: io.c is firmly part of the
> > library.
> 
> [And should therefore be available when used without python?]

I meant: Despite the fact that io.c might /appear/ to be specifically
written for the module because of the presence of PEP 3101 references,
it is part of the standalone (moduleless) library. However, _decimal.c
uses all parts of io.c except for a couple of functions at the bottom
of the file that are useful for debugging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________


More information about the Python-bugs-list mailing list