Author skrah
Recipients Amaury.Forgeot.d'Arc, Jim.Jewett, Ramchandra Apte, amaury.forgeotdarc, benjamin.peterson, casevh, ced, eric.smith, eric.snow, jjconti, mark.dickinson, pitrou, rhettinger, skrah, vstinner
Date 2012-03-07.10:28:56
SpamBayes Score 4.44089e-16
Marked as misclassified No
Message-id <>
In-reply-to <>
Jim Jewett <> 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 categorization
> let people focus on the core, that would be helpful, but it wasn't
> clear to me which files were part of the exported API and which were
> implementation details.  Are there are clear distinctions (type
> info/python bindings/basic arithmetic/advanced
> algorithms/internal-use-only/???)

OK, as a basis for discussion I've added:

I didn't mention the main reason why _decimal.c and libmpdec are in a flat
directory: Building the library first and then the module from the library
led to problems on at least Windows and AIX. That's why I started to treat
all libmpdec files as part of the module, list them as dependencies in
and let distutils figure everything out. Distutils also can figure out
automatically if a Mac OS build happens to be a "universal" build and things
like that.

The build process is very well tested by now and it took quite a while
to figure everything out, so I'd be reluctant to change the flat hierarchy.

> > ??python/ ?? ?? ??-> ??extended module tests
> I would really expect that to still be under tests, and I would expect
> a directory called python to contain code written in python, or at
> least python bindings.

Could you explain? The python/ directory contains,

> 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.

> > "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. All PEP 3101 formatting is part of libmpdec, because I like
the mini language. io.c only understands ASCII and UTF-8 fill characters.

It is the *library* tests that would fail under the Turkish locale
(if not for _mpd_strneq).

> Good enough, though I would rather see that as a comment near the assembly.

Comments how to enforce an ANSI build (much slower!) are in LIBTEST.txt
and now also in FILEMAP.txt.

> I'm not worried about the header files.  I am worried about what is
> exposed to python, but just documenting it (docstrings and the module
> .rst) may be OK.
> But I'm also worried that there may be fair amounts of code that are
> effectively dead after the "remove any names not in"
> importing trick.  If so, I would at least like that in some sort of
> #ifdef, so that people don't spend too much time trying to make sense
> of it.

It's the opposite: names from starting with an underscore
that are not in _decimal are removed. If I don't use that trick, I
end up with about 50 additional symbols from

import decimal # the C version

... '_ContextManager', '_Infinity', '_Log10Memoize', ...
Date User Action Args
2012-03-07 10:28:58skrahsetrecipients: + skrah, 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-07 10:28:57skrahlinkissue7652 messages
2012-03-07 10:28:57skrahcreate