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 Jim.Jewett
Recipients Amaury.Forgeot.d'Arc, Jim.Jewett, Ramchandra Apte, amaury.forgeotdarc, benjamin.peterson, casevh, ced, eric.smith, eric.snow, jjconti, lemburg, mark.dickinson, pitrou, rhettinger, skrah, vstinner
Date 2012-03-07.19:42:15
SpamBayes Score 0.0
Marked as misclassified No
Message-id <CA+OGgf7ZFuJHSP=mLgBLGg2mj1uHmjS-qq1kyuhMYZEaErV5Zw@mail.gmail.com>
In-reply-to <20120307102856.GA3236@sleipnir.bytereef.org>
Content
On Wed, Mar 7, 2012 at 5:28 AM, Stefan Krah
<stefan-usenet@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."
History
Date User Action Args
2012-03-07 19:42:26Jim.Jewettsetrecipients: + Jim.Jewett, lemburg, rhettinger, amaury.forgeotdarc, mark.dickinson, pitrou, vstinner, casevh, eric.smith, benjamin.peterson, jjconti, ced, skrah, Amaury.Forgeot.d'Arc, eric.snow, Ramchandra Apte
2012-03-07 19:42:16Jim.Jewettlinkissue7652 messages
2012-03-07 19:42:15Jim.Jewettcreate