[issue7652] Merge C version of decimal into py3k.

[Stefan Krah]

Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Jim Jewett <report at bugs.python.org> 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:

http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt

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 setup.py
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 deccheck.py, formathelper.py
etc.

> 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 decimal.py"
> 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 decimal.py 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 decimal.py:

import decimal # the C version
dir(decimal)

... '_ContextManager', '_Infinity', '_Log10Memoize', ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________