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