Message155070
Jim Jewett <report@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', ... |
|
Date |
User |
Action |
Args |
2012-03-07 10:28:58 | skrah | set | recipients:
+ 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:57 | skrah | link | issue7652 messages |
2012-03-07 10:28:57 | skrah | create | |
|