Stefan Krah <stefan-use...@bytereef.org> added the comment: Jim Jewett <rep...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue7652> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
