[Python-Dev] Be Honest about LC_NUMERIC [REPOST] (original) (raw)
Martin v. Löwis martin at v.loewis.de
Mon Sep 1 07:36:16 EDT 2003
- Previous message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Next message: [Python-Dev] Be Honest about LC_NUMERIC [REPOST]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Christian Reis <kiko at async.com.br> writes:
So, in an attempt to garner comments (now that we have 2.3 off the chopping block) I'm reposting my PEP proposal (with minor updates).
I can agree with the declared problem of the PEP, and the rationale for fixing it. Tim also convinced me that the approach taken to solve it is, technically, acceptable. So I only list issues where I disagree.
This change should also solve the aforementioned thread-safety problems.
It does not, and I think the PEP should point out that it doesn't.
This problem was initially reported as a problem in the GTK+ libraries [5]; since then it has been correctly diagnosed as an inconsistency in Python's implementation. However, in a fortunate coincidence, the glib library implements a number of LCNUMERIC-agnostic functions (for an example, see [6]) for reasons similar to those presented in this paper.
One of my early concerns (and I still have this concern) is that the contributors here appear to take the position "We have this fine code developed elsewhere, it seems to work, so we copy it. We don't actually have to understand this code". I would feel more comfortable if the code was written from scratch for usage in Python, with just the ideas borrowed from glib. Proper attribution of contributors and licensing are just one aspect, we really need the submitter of the code fully understand it, and be capable of reacting to problems quickly.
That said, I don't actually require that the code is written from scratch. Instead, a detailed elaboration of how precisely the implementation is approached, in the PEP, would be good.
The PEP should also point out deficiencies of the approach taken, e.g. the issue of spelling NaN, inf, etc. If it can be determined not to be an issue in real life (i.e. for all interesting platforms), this should be documented as well.
Regards, Martin
- Previous message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Next message: [Python-Dev] Be Honest about LC_NUMERIC [REPOST]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]