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 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 <rep...@bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
