This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients Amaury.Forgeot.d'Arc, Jim.Jewett, Ramchandra Apte, amaury.forgeotdarc, benjamin.peterson, casevh, ced, eric.smith, eric.snow, jjconti, lemburg, mark.dickinson, pitrou, rhettinger, skrah, vstinner
Date 2012-03-08.00:06:13
SpamBayes Score 5.55112e-16
Marked as misclassified No
Message-id <>
In-reply-to <>
Jim Jewett <> wrote:
> > OK, as a basis for discussion I've added:
> >
> Starting from that URL, I don't actually find

It's the 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.


> 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. e.g. has this comment:

Usage:  ../../../python | ../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
>>> locale.setlocale(locale.LC_ALL, 'tr_TR.utf8')
>>> from decimal import *
>>> Decimal("Infinity")

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)


> 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.
Date User Action Args
2012-03-08 00:06:15skrahsetrecipients: + skrah, lemburg, rhettinger, amaury.forgeotdarc, mark.dickinson, pitrou, vstinner, casevh, eric.smith, benjamin.peterson, jjconti, ced, Amaury.Forgeot.d'Arc, eric.snow, Ramchandra Apte, Jim.Jewett
2012-03-08 00:06:14skrahlinkissue7652 messages
2012-03-08 00:06:13skrahcreate