Jim Jewett <jimjjew...@gmail.com> added the comment: On Wed, Mar 7, 2012 at 5:28 AM, Stefan Krah <stefan-use...@bytereef.org> added the comment:
> OK, as a basis for discussion I've added: > http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt That is indeed very helpful. So helpful that now I understand well enough to have additional gripes. :D Starting from that URL, I don't actually find setup.py. I am assuming (but would prefer to have the file explicitly state) that _decimal.c and docstrings.h are the only source files, and that setup.py would be the only build infrastructure needed if you already had libmpdec.a. I'm not sure what sort of failures building in the normal order led to, but that is certainly something worth documenting, and (ideally) fixing. I didn't see any mention of the literature subdirectory, which makes me wonder if there were other files not listed in the map. (Not yet curious enough to verify for myself, though.) (*.txt files?) I suppose a subdirectory name like "python" makes sense when you look at the library as a C/C++ project that happens to provide python bindings; as part of the python core, it is misleading. It sounds like it should be named "extended_tests" or some such. (Note that this assumes it is strictly for tests; if you are also using it to provide extra functionality, or to generate some of the source code, then I agree with Benjamin that it should move to tools, and the generated code should have clear comments right at the top warning that it is generated.) Within the library, does io.[ch] really limit itself to ASCII? If so, then I don't know why you're worried about the Turkish i. If you mean generic text, then please don't specify ASCII. Within memory.[ch], how much of this configurability is useful (or even available) to a python user, as opposed to an extension writer? Or is it really just for testing? As in, would it be reasonable to just have a single header with a half-dozen #defines, but to replace that header when doing a memory-test build? Or at least to hide the alternative function definitions inside an obvious #ifdef, so that they don't take up memory and attention when they aren't applicable? Under the Bignum section, it mentions that functions from these files are ultimately used in _mpd_fntmul, but doesn't mention where that is (in the main _cdecimal.c) Also, when it talks about "large arrays", could you clarify that it isn't talking about arrays of values or even matrixes, it is just talking about numbers large enough that even representing them takes at least N bytes? >> 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. OK, let me rephrase. Is newton division exported to users, or used internally, or is it just for testing purposes? _mpd_qtest_newtondiv is documented as a testcase; I would rather see it move to a test file. Why can't it? If it is because of _mpd_qdiv_inf, _settriple, _mpd_qbarrett_divmod, _mpd_real_size (the only apparently internal things it uses), then why are these internal? Could they be exposed at least to test functions? If not, could they at least be wrapped in something that could exposed, such as _testhelp_mpd_qdiv_inf? >> > "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. [And should therefore be available when used without python?] > 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). Are those tests relevant to a _cdecimal built in to python itself? If not, then the comment is at least misleading. Would it make sense to have a directory for files that are used only for the standalone C library, but not when built as part of python? >> 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 would not have made the leap from that to "What to do if the assembly code needs to be replaced or even just changed." ---------- _______________________________________ 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
