[Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST] (original) (raw)

Guido van Rossum guido at python.org
Mon Sep 1 11:05:35 EDT 2003

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 strtodl() 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/)

More information about the Python-Dev mailing list