Message 155135 - Python tracker (original) (raw)

Jim Jewett <report@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; }

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.