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

[Guido van Rossum]

> A Seg, 2003-09-01 às 09:34, Guido van Rossum escreveu:
> > FWIW, I have the same feeling, but the idea of having to support
> > our own version of such code is even more uncomfortable.
> > 
> > Maybe at least we can detect platforms for which we know there is a
> > native conversion in the library, and not use the hack on those?
> 
>   In case people haven't noticed, the second version of the patch,
> submitted following the first patch, already does that.  It adds a
> configure.in check for glibc's strtod_l() and uses that instead of glib
> code whenever it's available.  Only on non-glibc systems is the glib
> code compiled in.

This doesn't address the first sentence of mine quoted above: I'm
uncomfortable with having this code being part of Python, given that
we have no expertise to maintain it long-term (nor should we need such
expertise, IMO).

Here's yet another idea (which probably has flaws as well): instead of
substituting the locale's decimal separator, rewrite strings like
"3.14" as "314e-2" and rewrite strings like "3.14e5" as "314e3", then
pass to strtod(), which assigns the same meaning to such strings in
all locales.  This removes the question of what decimal separator is
used by the locale completely, and thus removes the last bit of
thread-unsafety from the code.  However, I don't know if underflow can
cause the result to be different, e.g. perhaps 1.23eX could be
computed but 123e(X-2) could not???  (Sounds pretty unlikely on the
face of it since I'd expect any decent conversion algorithm to pretty
much break its input down into a string of digits and an exponent, but
I've never actually studied such algorithms in detail.)

--Guido van Rossum (home page: http://www.python.org/~guido/)