[Python-Dev] Be Honest about LC_NUMERIC [REPOST]

Martin v. Löwis martin at v.loewis.de
Mon Sep 1 07:36:16 EDT 2003


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
>     LC_NUMERIC-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



More information about the Python-Dev mailing list